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ABOUT THE COVER 


The marimba image on this month’s cover is from “More Bells and Whis¬ 
tles, ” a computer graphics music video with a synthesized sound track used 
to drive the animation. This process was developed by Wayne Lytle, a scien¬ 
tific visualization animator who premiered the work at the SIGgraph confer¬ 
ence in 1990. 

“More Bells and Whistles” received second place in the Technology and 
Computer Graphics Research category of the National Computer Graphics 
Association’s international animation competition in 1991. Lytle’s article de¬ 
scribing the technique, “Driving Computer Graphics from a Music Score, ” 
received first prize in the Social Sciences, Humanities, and Arts category of 
the IBM supercomputing competition this year. Below, Lytle describes his 
pioneering research for Computer readers. 



Wayne Lytle’s award-winning mu¬ 
sic video, “More Bells and Whis¬ 
tles,” correlates animation with 
music. It begins with a marimba 
solo (cover image), then adds aux¬ 
iliary percussion instruments 
(above). In the frame shown be¬ 
low, ball bearings ejected from a 
brass spout atop a marble column 
play the circular set of chimes seen 
in the background. 



Computer music drives 
graphics orchestra 

Wayne Lytle, Cornell National Supercomputer Facility 


I n a move away from previous 
methods, the images presented 
here are produced by a new tech¬ 
nique that automatically correlates the 
animation with the music through MIDI 
(Musical Instrument Digital Interface). 
The motion of each computer graphics 
instrument is synchronized with — and 
corresponds directly to — its synthe¬ 
sizer counterpart. 

A program called CGEMS (Com¬ 
puter Graphics/Electronic Music Sys¬ 
tem) analyzes the musical score for a 
given point in time and sets hundreds 
of graphics parameters accordingly. 

Since the motion of the graphics 
instruments involves movements that 
anticipate the beginning of a sound 
(such as a drumstick winding up) as 
well as following the sound (like the 
same stick moving away and onto the 
next drum), the entire musical con¬ 
text must be considered for each in¬ 
strument. This means that CGEMS 
analyzes currently sustaining notes, 
ones that will begin in the near future, 
and ones that have recently termi¬ 
nated. (Since knowledge of future 
events is required, this technique can¬ 
not be used in real time.) Individual 
instances of instruments are modeled 
via conventional computer graphics 
methods, then linked to MIDI chan¬ 
nels according to programmable 
CGEMS rules. 

I composed and recorded the music 


for “More Bells and Whistles” in my 
MIDI recording studio and rendered 
the graphics images with Wavefront 
Technology’s Advanced Visualizer 
animation package on CNSF’s IBM 
3090 complex. The piece begins with a 
marimba solo (cover image) and soon 
introduces a set of floating auxiliary 
percussion instruments, including 
cowbells, woodblocks, and electronic 
light drums (see frame at top left). 

The bass drum, snare drum, and high 
hat are unveiled next, followed by a 
set of capped organ pipes that stretch 
up and open as they release the 
sounds. Cymbal crashes are visualized 
by giant flashbulbs at each side of the 
stage. 

In the second half of the piece, a 
circular set of chimes emerges from a 
center-stage trapdoor and is played by 
ball bearings ejected from a brass 
spout atop a marble column (below, 
left). The exact trajectory of each ball 
is calculated by CGEMS so that the 
ball lands on the correct note at the 
correct time. 

The bells and green pods (which 
emit a “bwowb” Moog synthesizer 
bass sound) perform next, while the 
laser gun takes the stage. The laser 
correspond to the synthesizer lead, 
which reaches a climax after the tom¬ 
tom fill. At the end of the two-minute, 
15-second simulated concert, the in¬ 
struments fold up into their original 
positions, and the stage lights dim. 
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Computer-Generated Music 

Denis L. Baggi, Xi Computer Corporation 


While music transcends 
its time, it eagerly adopts 
the current technology. 
Musicians, like anyone 
else, use new instruments 
and procedures to reach 
their desired goals. In 
the age of computers, this 
is producing some 
fascinating results. 


C omputer music has existed as a formal application of computer science 
for at least 35 years. The idea has existed much longer. Ada Lovelace 
| suggested the use of machines in composition a century and a half ago. As 
far back as the Middle Ages, man merged technology and music in the 
form of clockwork mechanisms, carillons, and the like. The development of technology for 
fashioning pipes and mounting strings led to wind and string instruments, enrich¬ 
ing the music of the day, just as computers are enriching modern music. 

The field of musical composition is changing dramatically. Fast, easily pro¬ 
grammed computers allow the composer greater flexibility and a richer source of 
sounds. These advances result from a marriage of computer and musical expertise. 

Computer music has come to mean two things: the direct synthesis of sound by 
digital means and computer-assisted composition and analysis. 

The computer as a musical instrument. In the forties and fifties, new musical 
sounds were produced with the help of tape recorders and electronic devices, 
techniques promoted by adherents of Musique Concrete in Paris and Elektronische 
Musik in Cologne. While the first method favored processing of sounds that 
originate in “nature,” the second emphasized electronically produced sounds — 
from sine waves to noise. Both techniques contributed to new ways of defining 
musical composition. 

Because analog sound can be approximated by a series of numbers, computers 
can be used to store and manipulate sounds. 1 Early programs computed sound 
samples on digital tape which, when put through a digital-to-analog converter, let 
the programmed sound be heard. It was clear, even at an early stage, that the 
programming of such systems was cumbersome and time-consuming, in spite of 
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such computer languages as Music V 2 - 3 
to facilitate encoding. These languages 
implemented primitives — in the form 
of subroutines — for such synthetic in¬ 
struments as oscillators, envelope gen¬ 
erators, adders, and multipliers (similar 
to patches in analog computers). 

Researchers initially achieved inter¬ 
active control of the sound-synthesis 
process in the late sixties through the 
use of digitally controlled analog ma¬ 
chines. 4 Eventually, fast digital proces¬ 
sors 5 allowed digitally controlled, high¬ 
ly precise, and rapid sound synthesis, 
due to the direct connection to a host 
computer. This favored the design of 
serious musical instruments 6 and caused 
the emergence of standards. 7 

Composition and the solution of mu¬ 
sical and musicological problems. The 

advent of artificial intelligence prom¬ 
ised the application of computers, not 
as mere number crunchers, but as sym¬ 
bol manipulators. As a consequence, 
while numerical methods had been em¬ 
ployed in sound-synthesis processes, 
symbol manipulation and other AI tech¬ 
niques brought new solutions to music 
theory problems. 

Although algorithmic composition can 
be traced back to the Wurfelspiel of 
Mozart or Haydn (p. 48 of reference 8 
and p. 54 of reference 9), the first known 
computer-generated composition is the 
“Illiac Suite.” 9 It employed a variation 
of the Monte Carlo method in which 
notes of a composition written for a 
string quartet are generated at random 
and filtered according to a statistical or 
heuristic technique. 

Computer music has evolved to the 
point where such widely varying prob¬ 
lems as harmonization in Western mu¬ 
sic, Javanese music, jazz, and medieval 
Masses have been successfully under¬ 
taken. 8 Programming languages such as 
Fortran, Lisp, Snobol, and C have been 
widely used in the generation of music. 
Similarly, computer disciplines such as 
expert systems and neural networks 10 
have advanced computer-generated 
music. 

The pleasure of music comes in its 
perception, which — as opposed to con¬ 
text-free grammars and computer lan¬ 
guages — is hard to model within the 
constraints of digital systems. Advanc¬ 
es in computer-generated music paral¬ 
lel those in the field of visual percep¬ 
tion, such as graphics and visualization, 
and contribute increasingly to the main¬ 


stream of computer science. Music, with 
its rich syntax and subtle semantics, is 
an excellent vehicle for fundamental 
research in computer science, 11 which 
as a whole benefits from insights gained 
by such efforts. 

Contemporary trends. Unlike the 
devices of the forties and fifties, mod¬ 
ern hardware lets a sound be heard im¬ 
mediately after it has been conceived. 
Sound synthesis and algorithmic com¬ 
position tend to be merged. While re¬ 
search laboratories still study the na¬ 
ture and synthesis of sounds (IRCAM 
in Paris and CCRMA at Stanford Uni¬ 
versity), most users are satisfied with 
the sounds created by modern synthesis 
machines, which are inexpensive and 
readily available. 

A significant reason for this is the 
MIDI (Musical Instrument Digital In¬ 
terface) standard, 7 which has defined 
among other things the communication 
between musical devices such as ex¬ 
panders, synthesizers, keyboards, and 
MIDI instruments. These instruments 
may be wind controllers, saxophones, 
guitars, trumpets, drums, and even the 
digitized voice, as in the case of pitch- 
to-MIDI converters. MIDI is a hard¬ 
ware specification for a serial port and a 
protocol for transmitted symbols that 
may represent note, velocity, channel 
specification, controllers, and exclusive 
messages to control a device. At a high¬ 
er level, MIDI is also a standard for 
structuring files of musical data. 

With some sequencers (software that 
lets a home computer record and store 
pieces of music and communicate with 
the synthesizer), users can point direct¬ 
ly to a musical score on the screen to 
view the notes they have played or to 
hear and edit the whole orchestra. Such 
advanced user interfaces — unthink¬ 
able just two decades ago — dramati¬ 
cally change musicians’ approaches to 
composition and performance. 

The music and sounds generated by 
most of the projects in this issue have 
been produced by MIDI. The standard 
has made sound synthesis easy and avail¬ 
able to everybody, has permitted musi¬ 
cians to merge equipment from differ¬ 
ent manufacturers, and has encouraged 
researchers to exchange software and 
data. 

The exponential progress of comput¬ 
er technology has affected practically 
every discipline, scientific or humanis¬ 
tic. A yearly doubling in performance 


not only implies qualitative changes but 
also causes radical jumps in the use of 
technology, as shown by the different 
interfaces represented by punched cards, 
terminals in time-sharing systems, and 
personalized graphic user interfaces. 

The use of computers in music is rev¬ 
olutionizing established musical credos 
or procedures. While some Hollywood 
movies show nervous composers strug¬ 
gling with paper and pencil over a grand 
piano or trying to listen to an orchestra 
inside their heads — as Mozart does 
while he dictates his “Requiem” to 
Salieri in the movie Amadeus — musi¬ 
cians of the nineties click a mouse on 
the score in a window and immediately 
hear the effect through a synthetic or¬ 
chestra. No doubt the very essence of 
composing is changing. As yesterday’s 
difficulties are mastered, emphasis pass¬ 
es on to something new (the multiplica¬ 
tion taught today in elementary schools 
was a subject for the most advanced 
Italian university students in medieval 
times). 

Future trends. Musicians will no doubt 
exploit any advance in technology, dig¬ 
ital or otherwise — as they have for at 
least the last 40 centuries. Due to the 
rapid growth and general availability of 
standardized hardware, it is unlikely that 
specialized architectures may be widely 
diffused. The emergence of worksta¬ 
tions with built-in digital signal proces¬ 
sors connected to ordinary main boards 
encourages the adoption of standards. 

A major trend in modern computer 
music is that of multimediality . The com¬ 
bination of music and other expressive 
media is as old as music itself, as exem¬ 
plified by dance, ballet, and musical 
theater. A typical example is the combi¬ 
nation of video, such as graphic synthe¬ 
sis, and sound. Since the same technol¬ 
ogy underlies artistic creativity using 
these media, it is not unlikely that the 
traditional boundaries between artis¬ 
tic disciplines may begin to wither away, 
or that new kinds of artistic creation, 
possible only with computers, will 
come into being. 12 [See “About the 
Cover,” p. 4.] 

The projects in this issue. The articles 
represent a wide spectrum of research 
interests and show what is possible to 
obtain with contemporary technology. 

The main purpose of this issue, and of 
the music that goes with it, is to dispel 
the notion that computer music is only a 
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curiosity of acoustic research laborato¬ 
ries. 

Virtuosity alone does not make good 
music, and too much technique dimin¬ 
ishes the quality and mars the semantics. 
Just enough technique is needed for the 
correct transmission of the “musical 
message.” In other words, the technique 
— musical, electronic, digital, or what 
have you — must always serve the music. 

These articles were chosen because 
they represent a significant effort in the 
direction of music quality, at the level of 
tools, composition strategies, represen¬ 
tational models, and abstract method¬ 
ologies. 

Long and short articles show the vari¬ 
ation of activity in computer-generated 
music. The long articles give insight into 
important aspects of the topic, while the 
project overviews concisely show the 
rich and varied nature of this promising 
aspect of human endeavor. 

Audio examples for this special issue 
are available in the form of a compact 
disk or audiocassette and may be pur¬ 
chased according to the instructions on 
the next page. Maximum benefit is ob¬ 
tained by first reading the articles and 


then listening to the examples. The au¬ 
thors/composers do not hide the elec¬ 
tronic nature of their work. However, 
the musical quality is similar to, though 
distinct from, that generally associated 
with acoustic music. 

A t one extreme, computer musi¬ 
cians demand “faster” and 
“more powerful” operation the 
same way everyone else does. (Better 
hardware and software may contribute 
solutions to hard problems like analysis, 
where syntax depends on musical seman¬ 
tics.) At the other end, music encoding 
has been reduced in size (from pulse code 
modulation to MIDI) by at least four 
orders of magnitude. In fact, all known 
music may now be stored on a few com¬ 
pact disks (see M. Hawley, “The Personal 
Orchestra, or Audio Data Compression 
by 10,000:1,” in Computing Systems un¬ 
der “For more information.” ■ 
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this would have happened. The good work, 
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Oakland, California, placed equipment and 
work at our disposal to assemble the master 
for the audio examples. The whole staff of 
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Conference on Object-Oriented Programming 
Systems, Languages, and Applications 


6-11 October 1991 

Phoenix Civic Plaza, Phoenix, AZ 


INVITATION TO OOPSLA '91 

John Richards, IBM Watson Research Center 
Conference Chair 

We invite you to participate in OOPSLA ’91, the sixth annual 
conference on Object-Oriented Programming Systems, 
Languages, and Applications. The conference continues the 
tradition of bringing you the very best research and 
technology in this increasingly important field. Our program 
committee has selected an outstanding set of papers. We 
have combined these with excellent panel discussions, 
tutorials, workshops, demonstrations, and exhibits so you are 
sure to find much ot value. OOPSLA '91 will be exciting and 
enjoyable. The facilities are superb, Phoenix in October is 
delightful, and the spirit of the Southwest will contribute to 
our celebration. Please join us. 

REGISTRATION AND 
INFORMATION_ 

An advance program brochure containing detailed 
tutorial and workshop information, registration forms, 
housing information, and preliminary technical 
program information will be mailed in July 1991. If 
you attended the 1989 or 1990 OOPSLA conferences 
or if you are a member of SIGPLAN, you will 
automatically receive a copy of the advance program 
brochure. Otherwise, please contact: 

Carole Mann 

OOPSLA ’91 Registration Chair 
Gentleware Corporation 
2060 Goldwater Court, 

Maitland, Florida 32751 
Phone: +1-407-628-3602 

Fax: +1-407-628-3186 

Email: mann@eola.cs.ucf.edu 

EXHIBITS_ 

Running concurrently with the technical program will 
be an exposition of object-technology products and 
services. In addition to continuous exposure in their 
booths, exhibitors will also have the opportunity to 
make scheduled presentations as part of the Vendor 
Forum, an integral portion of the OOPSLA ’91 
program. For additional information on exhibits please 
contact: 

Timlynn Babitsky and Jim Salmons 
OOPSLA ’91 Exhibits Co-Chairs 
Phone/Fax: +1-803-957-0648 


TECHNICAL PROGRAM 
INTRODUCTION_ 

Alan Snyder, Hewlett-Packard Laboratories 
Technical Program Chair 

This year’s technical program includes 23 papers presented in 
eight sessions. The papers were selected from a great many 
submissions, and cover the key areas of ongoing research as 
well as experience obtained using object technologies. 

New at OOPSLA this year are experience reports. 
Experience reports will be short presentations by 
practitioners who report on their real world 
experience using object technologies. To inaugurate 
this new format, we have selected ten experience 
reports that are sure to be of interest to practitioners 
and researchers alike. 

SESSIONS 


KEYNOTE ADDRESS 
Object-Orientation and Transaction 
Processing: Where Do They Meet? 

John Tibbetts, Kinexis 

IMPLEMENTATION 

Eliot Moss, University of Massachusetts 

Making Pure Object-Oriented Languages 
Practical 

Craig Chambers, Stanford University 
David Ungar, Sun Laboratories 

Parallel Generational Garbage Collection 

Ravi Sharma, University of Pittsburgh 
Mary Lou Soffa, University of Pittsburgh 

Using Key Object Opportunism to Collect Old 
Objects 

Barry Hayes, Stanford University 

ENVIRONMENTS 

Pierre Cointe, Rank Xerox 

Integrating Information Retrieval and 
Domain Specific Approaches for Browsing 
and Retrieval in Object-Oriented Class 
Libraries 

Richard Helm, IBM Watson Research Center 
Yoelle S. Maarek, IBM Watson Research Center 

Portia: An Instance-Centered Environment 
for Smalltalk 

Eric Gold, IBM Watson Research Center 
Mary Beth Rosson, IBM Watson Research Center 


EXPERIENCE I 

Mark Linton, Silicon Graphics 

Developing a GUIDE Using Object-Oriented 
Programming 

Joseph A. Konstan, University of California, Berkeley 
Lawrence A. Rowe, University of California, Berkeley 

Building Generic User Interface Tools: An 
Experience With Multiple Inheritance 

Nuno Guimaraes, AT&T Bell Laboratories 

Composite Multimedia and Active Objects 

Simon Gibbs, Universite de Gendve 

TYPES 

William Cook, Apple Computer 

Static Type Checking and Run-time Dispatch 
of Multi-Methods 

Rakesh Agrawal, IBM Almaden Research Center 
Linda G. DeMichiel, IBM Almaden Research Center 
Bruce G. Lindsay, IBM Almaden Research Center 

A Static Type System for Message Passing 

Giorgio Ghelli, Universita' di Pisa 

Object-Oriented Type Inference 

Jens Paisberg, Aarhaus University 
Micheal I. Schwartzbach, Aarhaus University 

SOFTWARE ENGINEERING 

Mayer Schwartz, Tektronix 

Coherent Models for Object-Oriented 
Analysis 

Fiona Hayes, Hewlett-Packard Laboratories 
Derek Coleman, Hewlett-Packard Laboratories 

An Empirical Study of the Object-Oriented 
Paradigm and Software Reuse 

John A. Lewis, Virginia Tech 
Sallie M. Henry, Virginia Tech 
Dennis G. Kafura, Virginia Tech 
Robert S.Schulman, Virginia Tech 

Object-Oriented Software Design Metrics: 

A Measurement Theory Approach 

Shyam R. Chidamber, Massachusetts Institute of Technology 
Chris F. Kemerer, Massachusetts Institute ot Technology 

CONCURRENCY AND PERSISTENCE 

Aki Yonezawa, University of Tokyo 

Communication as Fair Distribution of 
Knowledge 

Jean-Marc Andreoli, ECRC 
Remo Pareschi, ECRC 

The Kala Basket: A Semantic Primitive 
Unifying Object Transactions, Access 
Control, Versions and Configurations 

Sergui S. Simmel, Samsung Software America 
Ivan Godard, Penobscot Research Center 

An Extensible Kernel Object Management 
System 

Rahim Yaseen, University of Florida 
Stanley Y. W. Su, University of Florida 
Herman Lam, University of Florida 

EXPERIENCE REPORTS I 

Grady Booch, Rational 

Oral presentations on real-world experience 
using object technologies 

Tom Wisdom, Hewlett-Packard 
Phillip M. Yelland, Active Book Limited 
Kirk Thompson, Quincy Street Corporation 
Aleks Gollu, Teknekron Communications Systems 
Mark D. Grover, Oberon Software 
LANGUAGE 

Ole Lehrmann Madsen, Aarhaus University 

Islands: Aliasing Protection in Object- 
Oriented Languages 

John Hogg, Bell-Northern Research 

EQUATE: An Object-Oriented Constraint 
Solver 

Micheal R. Wilk, Cornell University 

























Object-Preserving Class Transformations 

Paul L. Bergstein, Northeastern University 

EXPERIENCE REPORTS II 

Dave Thomas, Object Technology International 

Oral presentations on real-world experience 
using object technologies 

Joseph Cascio, Cadre Technologies 

David M. Lasker, Rational 

Craig Damon, Progress Software 

Beth Lavender, MITRE Corporation 

Evelyn Van Orden, Xerox SIS 

EXPERIENCE II 

Rebecca Wirfs-Brock, Tektronix 

Experiences in DBMS Implementation Using 

an Object-Oriented Persistent Programming 

Language and a Database Toolkit 

Eric N. Hanson, Wright Research and Development Center 

Tina M. Harvey, Air Force Institute of Technology 

Mark A. Roth, Air Force Institute of Technology 

Symbolic and Spatial Database for 

Structural Biology 

Dan Benson, University of Washington 

Greg Zick, University of Washington 

Reengineering of Old Systems to an Object- 

Oriented Architecture 

Ivar Jacobson, Objective Systems 

Fredrik Lindstrom, Objective Systems 

SPECIAL SESSION 

Methodologies Compared 

Steven Weiss, Wayland Systems 

Peter Coad, Object International 

Tony Wasserman, IDE 

Norm Kerth, Elite Systems 

A full afternoon of four parallel sessions that use the various 
design techniques of the speakers to work on a common 
problem. The parallel sessions will be followed by a joint 
panel that discusses and challenges the design decisions of 
the participants. 

PANELS_ 

Can Structured Methods be Objectified? 

Kent Beck, MasPar (moderator) 

Grady Booch, Rational 

Peter Coad, Object International 

Meilir Page-Jones, Wayland Systems 

Paul T. Ward, Software Development Concepts 

Issues in Moving from C to C++ 

David Reed, Saber Software, Inc. (moderator) 

Ted Goldstein, Sun Laboratories 

Martin Cagan, Interactive Development Environments 

Barbara Moo, AT&T 

Formal Techniques for Object-Oriented 
Software Development 

Dennis de Champeaux, Hewlett-Packard Laboratories 
(moderator) 

Pierre America, Philips Research Laboratories 

Derek Coleman, Hewlett-Packard Laboratories 

Roger Duke, University of Queensland 

Doug Lea, Syracuse University and SUNY-Oswego 

John Mitchell, Stanford University 

The Economics of Software Reuse 

Martin Griss, Hewlett-Packard Laboratories (moderator) 

Sam Adams, Knowledge Systems Corporation 
Howard Baetjer, George Mason University 
Brad Cox, StepStone, Inc. 

Adele Goldberg, ParcPIace Systems 

Managing the Transition to Object-Oriented 

Technology 

Timothy Korson, Clemson University (moderator) 

Rick Samco, Mentor Graphics 
Tim Hilgenberg, Hewitt Associates 


Chris Jette, Ascent Logic 
David Taylor, independent consultant 
Reed Phillips, Knowledge Systems 

OOP and Al 

Mamdouh Ibrahim, EDS/AI Services (moderator) 

Daniel Bobrow, Xerox PARC 

Carl Hewitt, Massachusetts Institute of Technology 

Jean-Francois Perror, LAFORIA 

Reid Smith, Schlumberger Research Laboratories 

Howard Shrobe, Symbolics 

TUTORIALS_ 

Object-oriented technology is new and evolving rapidly. 
Taking full advantage of this technology requires ongoing 
education and training. OOPSLA's two full days of tutorials 
offer a balance of general and specific courses, of research- 
based and practice-based approaches, and of basic and 
advanced topics. 

The Behavior of Behavior 

Jerry L. Archibald, IBM Watson Research Center 

Object-Oriented Programming in Modula-3 

Samuel Harbison, Pine Creek Software 
Jan Aikins, Aion Corp. 

Object-Oriented Design 

Grady Booch, Rational 

Object-Oriented Programming with Expert 
Systems 

Paul Harmon, ObjectVision, Inc. 

Case Studies in Smalltalk 

Wilt LaLonde, The Object People 
John Pugh, The Object People 

CLOS 

Jon L. White, Lucid, Inc. 

Concepts of Object-Oriented Programming 

Dr. Raimund Ege, Florida International University 

Introduction to C++ 

Stan Lippman, AT&T Bell Laboratories 

Object-Oriented Database Systems 

Peter Lyngbaek, Hewlett-Packard Laboratories 

Object-Oriented Modeling and Design 

James Rumbaugh, General Electric Corporate R&D 
Michael Blaha, General Electric Corporate R&D 

Object-Oriented Project Management 

Richard Dellinger, ParcPIace Systems 

Software Development with Eiffel 

Jim McKim, Hartford Graduate Center 

Query Languages and Processing in OODBs 

Gail Mitchell, Brown University 

Using Polymorphism 

David N. Smith, IBM Watson Research Center 

Object-Oriented Frameworks 

Ralph Johnson, University of Illinois 
Rebecca Wirfs-Brock, Tektronix 

Concepts of Object-Oriented Data Modeling 
and Programming 

Professor Karl Lieberherr, Northeastern University 

The Design and Management of C++ Class 
Libraries 

Arthur J. Riel, Empathy, Inc. 

Programming in DRAGOON 

Colin Atkinson, University of Houston—Clear Lake 
Stephan Goldsack, Imperial College 
Andrea DiMaio, TXT S.p.A. 

Object-Oriented Application Development in 
the Corporate Environment 

Jefferey G. Bonar, Guidance Technologies Inc. 

An Introduction to the BETA Programming 
Language 

Ole Lehrmann Madsen, Aarhus University 
Birger Miller-Pedersen, Norwegian Computing Center 


WORKSHOPS_ 

Workshops provide a forum for experts in an area to discuss 
current topics and present their latest work. Attendance is 
through submission and acceptance of a short position paper 
related to the topic of the workshop. Papers are due August 1, 
1991 and those submitting will be notified of acceptance or 
rejection by September 1,1991. Refer to the advance 
program for submission information. 

Finding Objects: Practical Approaches 
Peter Coad, Object International, Inc. 

Objects in Large Distributed Applications 
Peter Dickman, Computer Lab, New Museums’ Site 
Object-Oriented Program Development 
Environments 

Dmitry Lenkov, Hewlett-Packard California Language 
Laboratory 

Real-Time and Embedded Systems 

Brian M. Barry, Object Technology International, Inc. 

Object-Oriented Modeling (OOM) 

Robert Holibaugh, Software Engineering Institute, 

Carnegie Mellon University 

Object-Oriented (Domain) Analysis 

Dennis de Champeaux, Hewlett-Packard Laboratories 

Garbage Collection in Object-Oriented 
Systems 

Paul R. Wilson, Interactive Computing Environments Lab, 
University of Illinois at Chicago 

Reflection and Metalevel Architectures in 
Object-Oriented Programming 

Mamdouh H. Ibrahim, Electronic Data Systems 

Reuse 

John D. McGregor, Clemson University 

Towards an Architecture Handbook 

Bruce Henderson, University of Essex 

The Bottom Line: Using 00 in the 
Commercial Environment 

K.C. Burgess Yakemovic, NCR Corporation. Human Interface 
Technology Center 

DEMONSTRATIONS_ 

In an effort to provide a venue for the very latest work in 
applying object-oriented technology, we are still soliciting live 
demonstrations of object-oriented systems to be presented 
during the conference. In particular, we are seeking 
demonstrations of both commercial and in-house 
applications, as well as academic and corporate research 
efforts. 

Here are some Demonstrations already in the program: 

Applying the Booch Notation 

Grady Booch, Rational 

The C++ Demeter System 

Karl J. Lieberherr, et al, Northeastern Univ. 

Open Zeitgeist: A Modular OODBMS 

Jose A. Blakeley, Texas Instruments 

G++: An Object-Oriented Design and 
Prototyping Environment for Manufacturing 
Systems 

Ginseppe Menga, Politecnico di Torino, Italy 

The Scorpion Meta Software Engineering 
Environment 

Richard Snodgrass, University of Arizona 

PORTIA: A Software Environment for 
Smalltalk 

Eric Gold, IBM Watson Research Center 

Additional submissions contact: 

Sam Adams 

OOPSLA '91 Demonstrations Chair 
Phone: +1-919-481-4000 


Sponsered by the Association for Computing Machinery's Special 
Interest Group on Programming Languages (ACM/SIGPLAN) 






















U Formula: 

A Programming 
mjf Language 
l ' . . for Expressive 
I Computer Music 

David P. Anderson, University of California at Berkeley 
Ron Kuivila, Wesleyan University 


Formula, a language for 
controlling synthesizers, 
can model the 
expressiveness of a 
human performance. It 
supports algorithmic 
composition, interactive 
performance, and 
programmed 
interpretation of 
traditional scores. 


C onventional programming systems have limited utility for composing and 
playing computer music because the languages themselves lack features 
relating to time and concurrency, and their runtime systems cannot 
provide the needed levels of output timing accuracy or input response speed. 

Formula (an abbreviation for Forth Music Language) is a programming system 
that addresses these problems. It runs on Atari ST and Macintosh personal 
computers that control music synthesizers, typically via a MIDI interface.' For¬ 
mula therefore does not specify waveform synthesis algorithms; its abstractions 
begin at the level of “note” and extend upward. 

We based Formula on the Forth language (see the sidebar) and added many new 
functions and control structures. We designed Formula for the following applica¬ 
tions: 

•Programmed score interpretation. You can use Formula to represent static 
musical scores, as with Darms 2 or Score. 3 In addition, you can use Formula to 
express interpretive elements (for example, tempo and volume fluctuation) often 
not present in scores. 

• Algorithmic composition. Formula’s constructs are executable. Therefore, the 
features of the underlying programming language (for example, control structures 
and parameterized procedures) are available at any point. This lets you represent 
iteration, nesting, and randomness. 

• Interactive systems. A Formula program plays its output, normally with very 
accurate timing while it executes. Also, Formula programs respond rapidly to 
input, so they can define “intelligent instruments” that interact with a performer 
using input devices such as MIDI instruments or a computer keyboard and mouse. 

Formula uses concurrent processes that share a single address space; its runtime 
system schedules the processes. Formula offers several process types: 

• Note-playing processes compute sequences of pitches and play these pitches as 
notes or chords. A separate note-playing process typically represents each “voice” of 
a piece of music. You can collect note-playing processes into groups. 


12 


8-9162791/0700-0012S01.00 © 


COMPUTER 









$ 

(pitch —; 

play a note of the given pitch) 

m$ 

(pi ... pm m 

— ; play m notes in sequence) 

$n 

(pi ... pn n - 

■ - -; play n notes as a chord) 


Figure 1. Formula's note-playing words. 


• Auxiliary processes are attached to 
note-playing processes or groups to sup¬ 
ply note parameters such as volume, 
duration, and articulation. There are 
several subtypes of auxiliary processes: 
shapes control volume and articulation, 
time deformations generate tempo fluc¬ 
tuations, and timing sequence genera¬ 
tors produce rhythmic sequences. 

•Input-handling processes execute 
when input arrives from a particular 
device (keyboard, mouse, MIDI). In 
response to input, they generate output 
themselves or create note-playing pro¬ 
cesses to do so. 

Formula’s factorization into pro¬ 
cesses provides several advantages. You 
can easily express concurrent musical 
voices. You can also exploit the struc¬ 
ture in each musical parameter. For 
example, you can write a repeating 
rhythm as a loop, even if the corre¬ 
sponding pitches do not repeat. 

Factorization into processes also facil¬ 
itates the specification of musical “ex¬ 
pression.” For example, the timing of a 
piece is typically divided into the notated 
timing, specified by the timing sequence 
generator process, and the expressive 
fluctuations in tempo, specified by time 
deformation processes. These specifica¬ 
tions are in separate sections of code, 
and you can modify them independently. 
You can factor tempo fluctuation itself 
into several time deformations and su¬ 
perimpose the deformations to produce 
the actual note timing. 

In this article, we give an overview of 
the Formula language and describe two 
representative Formula programs. A 
complete description of the Formula 
language is available elsewhere. 4 We 
have described the process scheduling 
techniques used in Formula’s runtime 
system in other articles. 5 - 6 

Basic features of 
Formula 

In this section, we describe Formula’s 
basic facilities for playing notes, creat¬ 
ing parallel note-playing processes, and 
grouping these processes. 

Playing notes and chords. Figure 1 
shows Formula’s note-playing functions, 
or words, in Forth terminology. The 
basic note-playing word is $. For exam¬ 
ple, 60 $ plays middle C (60 is the MIDI 
pitch number for middle C). In addition 


to starting the note (anal¬ 
ogous to pressing a pi¬ 
ano key), the function 
stops the note (lifts the 
key). The default dura¬ 
tion is a quarter note, 
but you can express oth¬ 
er time intervals as frac¬ 
tions of whole notes or directly in milli¬ 
seconds. Also, $ pauses the calling pro¬ 
cess; the default is again a quarter note. 
Thus, 

60 $ 64 $ 67 $ 72 $ 

plays a C major arpeggio in quarter 
notes, with each note ending precisely 
when the next one begins. 


You can name pitches using a, b,..., g. 
These words return a pitch number with¬ 
in a current octave, initially the octave 
beginning at middle C. Prepending a 
plus or minus sign specifies a pitch in 
the next higher or lower octave. Ap¬ 
pending a plus or minus sign specifies a 
sharp or flat. For example, +g- specifies 
the G-flat in the octave above the cur¬ 
rent octave, n oct sets the current oc- 


The Forth language 

Charles Moore originally developed the Forth 1 language for control applications 
using microcomputers. Forth is well-suited to computer music for several rea¬ 
sons. Its execution model is simple and can be implemented efficiently on small 
machines. Moreover, it is extensible and can serve as a basis for defining new 
language constructs, imposing few requirements on their syntax. Forth also pro¬ 
vides a shell-like interpreter, allowing programmers to enter and dynamically test 
definitions. 

Forth functions, called words, are invoked using a postfix notation without de¬ 
limiters. A data stack stores intermediate results. Most words take their argu¬ 
ments and return their results on the stack. Variables and constants are also 
words (a constant, when executed, leaves its value on the stack; a variable 
leaves its address). Words are defined as follows: 

: print-sum (n m - - -; add two numbers and print their sum) 


This example defines a word print-sum that adds its two arguments using “+” 
and prints the result using (these words are predefined). The parenthesized 
comment shows the word’s effect on the data stack as before — after, print-sum 
expects two numbers (n and m) and removes them both. 

Forth words are stored in vocabularies. Forth maintains a search list of vocabu¬ 
laries, and looks up names by scanning vocabularies in this list. The programmer 
interacts via the interpreter. Normally, the interpreter scans keyboard input, looks 
up each word in the list of active vocabularies, and executes the corresponding 
function. If the interpreter does not find a name, it scans the text as a number (if 
possible) and pushes it on the data stack. When the interpreter is in compile 
mode (for example, while scanning a word definition), it looks up words and com¬ 
piles their addresses into the current definition. 

Forth provides a mechanism for specifying the compile-time as well as the run¬ 
time behavior of a word. Programmers can use this mechanism to define words 
that implement control structures. For example, the words do and loop are de¬ 
fined this way and provide Forth’s iteration construct: 

10 0 do (print the numbers 0 .. 9) 

loop 

Reference 

1. L. Brodie, Starting Forth, Prentice Hall, Englewood Cliffs, N.J., 1981. 
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:ap cadence 
g r a r b r 6$ 
c e g +c $4 

;ap 


Figure 2. The definition of a note-playing word and the score fragment it plays. 


:ap scale 

(high low — ; play a chromatic scale) 

::a P 

(create a new process to make this asynchronous) 

[ 2 params ] 
do i $ loop 

(pass loop limits to new process) 

;;ap 


;ap 



Figure 3. [n params] moves entries from the stack of the parent process to the 
stack of the child process. 


:ap trio 


:; gP 

(create a group) 

::ap soprano ;;ap 
::ap alto ;;ap 

(create processes within group) 

bass 


;;gp 

ending 

(continue here when group is empty) 

;ap 



Figure 4. Creating a group. 



tave to n (middle C is octave 3). The 
word r returns a special pitch number 
(zero) that represents a rest. 

:ap and ;ap delimit the definition of a 
note-playing word. They are like the 
colon and semicolon, but also add to the 
search list a vocabulary ap-defs contain¬ 
ing words relevant to note-playing pro¬ 
cesses. Figure 2 shows the definition of 
a note-playing word and the score frag¬ 
ment it plays. 

Note-playing processes. The follow¬ 
ing construct creates a note-playing pro¬ 
cess: 

:ap asynch-scale 
::a P 

c d e f g 5$ 

;;ap 

;ap 

Formula executes the code within the 
::ap ... ;;ap construct as a separate pro¬ 
cess. The parent process continues after 
;;ap (it does not wait for the child to 
finish). The child process exits when it 
reaches ;;ap. Thus, if you run asynch- 
scale from the Forth interpreter, it will 


play in the background while the inter¬ 
preter handles further terminal keyboard 
input. 

This type of construct, called an em¬ 
bedded process definition, is used 
throughout Formula. It lets you embed 
the code for a process within the proce¬ 
dure that creates the process, rather 
than in a separate (and perhaps hard- 
to-find) place. 

When you create a process, often you 
must put initial parameters on its stack. 
In the example shown in Figure 3, 
[ 2 params ] tells Formula to move the 
top two entries from the stack of the 
parent process to the stack of the child. 

For many quantities, such as the “cur¬ 
rent octave” used in pitch-naming, you 
need a separate copy in each process. 
Formula provides a mechanism for de¬ 
fining per-process variables (called 
pquans). By default, a pquan name re¬ 
fers to its instance in the currently exe¬ 
cuting process. 

Note-playing process groups. A group 
is a collection of note-playing processes 
and can contain other groups as elements. 
You can control (suspend, resume, or 


kill) a group as a unit. If you attach 
auxiliary processes to a group, they af¬ 
fect the tempo or volume of all notes 
generated by processes in that group and 
its descendants. The ::gp... ;;gp construct 
shown in Figure 4 creates a group. 

When a process P executes ::gp, it 
temporarily becomes a group. Formula 
creates a new process Q, which executes 
the code following ::gp and becomes the 
sole member of the new group. Q may 
create additional processes in the group 
using ::ap. Q exits when it reaches ;;gp. 
When all the processes in the group 
have exited, P becomes a process again 
and resumes execution after ;;gp. In the 
example in Figure 4, trio temporarily 
changes the calling process P into a group 
containing three processes that execute 
soprano, alto, and bass, respectively. P 
resumes and executes ending when these 
three processes have finished. 

Interactive process control. A typical 
Formula program creates many pro¬ 
cesses. Usually you need to interact with 
only a few of them, the visible processes, 
and can ignore the rest. Each visible 
process has a unique ID (a small integer) 
and a symbolic name. The following vari¬ 
ant of ::ap creates a visible process: 

:a P trio 
::ap” trio” 

(trio 

;;ap 

;ap 

The string following ::ap” (trio, in this 
case) is the symbolic name. Formula 
assigns the ID. The word .all prints a list 
of all existing visible “objects” (pro¬ 
cesses and groups), including their 
names, IDs, and states. Figure 5 lists the 
words that manipulate visible objects. 

Time control structures. As a note¬ 
playing process plays notes, it advances 
through a sequence of time positions 
(the start and end times of the notes). 
Formula provides control structures to 
specify limits on the time consumed by 
a block of code. The construct 

maxtime (n -) 

maxend 

specifies that the enclosed code is to 
consume at most n units of time in the 
process’s virtual time system. (We de¬ 
scribe virtual time systems in a later 
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suspend 

(ID-; suspend an object) 

resume 

(ID — ; resume a suspended object) 

kill-all 

(-; kill all mortal objects) 

kill 

(ID-; kill a specific object) 

immortal 

(-; make the calling process immune to kill-all) 


Figure 5. Words to manipulate visible objects. 


:ap foo 


"tsg 


begin 114 irnd & again 

(irnd generates random numbers) 

;;sg 

811 maxtime 

(do the following for 8 whole notes) 

begin c $ again 
maxend 

(play C’s in a loop) 

;ap 



Figure 6. Playing a bounded-length sequence of random-length notes. 


rap crescendo 


::shl 

(install new volume shape in local context) 

0 100 111 oseg 
;;sh 

(volume shape process executes this code) 

c e d f 4$ 

;ap 

(play some notes) 


Figure 7. Using a shape for a linear volume increase. 


Table 1. The syntax for defining auxiliary processes. 


Defining Syntax 

Location 

Purpose 

Process Type 

"tsg... ;;sg 

Self 

Note duration 

Sequence generator 

::shl ... 

;;sh 

Local context 

Volume control 

Shape 

::sh2... 

;;sh 

Local context 

Volume control 

Shape 

::gshl . 

.. ;;sh 

Global context 

Volume control 

Shape 

::gsh2... ;;sh 

Global context 

Volume control 

Shape 

::ash ... 

;;sh 

Local context 

Articulation 

Shape 

::tdl ... 

;;td 

Local context 

Tempo control 

Time deformation 

::td2... 

;;td 

Local context 

Tempo control 

Time deformation 

"gtdl . 

.. ;;td 

Global context 

Tempo control 

Time deformation 

::gtd2. 

.. ;;td 

Global context 

Tempo control 

Time deformation 


section.) If the code exceeds the limit, 
the system unwinds the stack and trans¬ 
fers control to the statement following 
maxend. 

Figure 6 shows code that plays a se¬ 
quence of random-length notes. The 
sequence lasts exactly as long as eight 
whole notes. Other constructs specify a 
lower time bound on a code block, en¬ 
forced by repetition or waiting. You can 
nest these structures; outermost struc¬ 
tures have priority. 

Auxiliary processes 

The $ words take only pitch argu¬ 
ments. You specify other parameters 
(such as volume and duration) using 
per-process variables and auxiliary pro¬ 
cesses. You can also use auxiliary pro¬ 
cesses to change the tempo of note¬ 
playing processes. An auxiliary process 
can be attached to either a process or a 
group. If you attach it to a group, it 
affects all processes in the group and its 
descendants. 

Attaching auxiliary processes. A note¬ 
playing process P has local and global 
contexts. By default, P's local context is 
itself, and its global context is the top- 
level group containing it (or, if P is top- 
level, P itself). 

Every note-playing process and group 
contains slots, each of which can con¬ 
tain an auxiliary process (the set of slots 
is extensible). Table 1 shows how em¬ 
bedded auxiliary process definitions 
create new processes in the slots of the 
calling process or its local or global con¬ 
texts. The semantics of these constructs 
are as follows: When a note-playing pro¬ 
cess reaches the start of the construct 
(say, ::shl), the process currently in the 
shl slot of its local context is killed. 
Formula creates a new process, execut¬ 
ing the embedded code, and installs it in 
that slot. The constructs also add vocab¬ 
ularies ( sg-defs , sh-defs, and td-defs) 
relevant to the type of process being 
defined. You can specify that parame¬ 
ters be passed to the new process using 
[ n params ]. For example, in Figure 7, 
the volume shape causes the notes to be 
played with a linear volume increase of 
0 to 100 over a whole-note period. (We 
modified Forth’s parser to accept 
rational-number notation. For exam¬ 
ple, 3116 represents a duration of 3/16— 
a dotted eighth note, if time units are 
equated with whole notes.) 


Procedural concatenation functions. 

A procedural concatenation function 
(PCF) is a process that defines a func¬ 
tion of time by calling PCF primitives. 
Each primitive represents a function 
defined over a time interval. The func¬ 
tion defined by the PCF process is the 
concatenation of the primitive functions. 
Figure 8 gives an example. 

A PCF definition can have parame¬ 
ters, use control structures, and call 
other PCF definitions. For example, 


Figure 9 shows the concatenation of m 
instances of swell. 

Shapes. Shapes are PCFs whose val¬ 
ues control volume or articulation. 
(Shapes might also be used to control 
timbre, spatial location, or other param¬ 
eters, but we have not yet implemented 
these uses.) Figure 10 lists the primitives 
for shape definitions that Formula pro¬ 
vides; others are easy to define. The prim¬ 
itive oseg represents a segment ranging 
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Functior 

3 

: swell 

0 3 10 seg 2 

3 0 20 seg 

value 
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0 

lime 

10 20 30 


Figure 8. An example of function definition by procedural concatenation. The 
word swell defines the function shown; seg (yl y2 dt-;) is a procedural con¬ 

catenation function primitive representing a linear change from yl to y2 over an 
interval dt. 


: many-swells (m- 

; m concatenated swells) 

Odo 


swell 


loop 



Figure 9. Concatenation of instances of swell. 


oseg 

(yl y2 dt 

— ; open linear segment) 

cseg 

(yl y2 dt 

— ; closed linear segment) 

ocon 

(y dt - - -: 

; open constant segment) 

ccon 

(y dt - - - 

; closed constant segment) 


Figure 10. Primitives for shape definitions. 


2 0 

do 


0.5 1.5 111 

seg 

(a) loop 


2.0 | - 


r 




°'°o.o 

1.0 

2.0 

(b) 



Undeformed 


Deformed 

time 


time 

1.5—► 

TD 

—>-1.375 

0.5— 


—► 0.625 

(c) 




Figure 11. A time deformation pro¬ 
cess executes a procedural concatena¬ 
tion function (a). The resulting tempo 
function is integrated over its domain 
(b) to deform a sequence of time in¬ 
tervals (c). 


from yl to y2 over an 
interval dt. A shape 
primitive is either open 
or closed. The shape 
value at the boundary 
between two primi¬ 
tives is determined by 
the first primitive if the 
first primitive is closed; 
otherwise, by the sec¬ 
ond. 

The volume of 
notes played using $ 
words is the sum of 
up to two local vol¬ 
ume shapes, up to two 
global volume shapes, 
and a per-process 
variable $volume. 
The sum must lie in 
the range [-128,127]; 
it is then converted to 
MIDI’s [0,127] scale. The actual loud¬ 
ness function depends on the synthe- 


Shapes also control articulation (stac¬ 
cato, legato, and so on). A note’s “delay 
until release” (denoted D r ) can differ 
from its “delay until next note” (denot¬ 
ed D„). D r may be longer (causing note 
overlap or legato) or shorter than D„. 
We call this timing relationship articu¬ 
lation. In Formula, an articulation shape 
that determines D r , possibly as a func¬ 
tion of D„, controls the articulation for 
each note-playing process. 

The value returned by an articulation 
shape includes both a number X and an 
absolute , relative, or ratio mode. An ar¬ 
ticulation shape generates X using shape 
primitives such as oseg, and can call ab¬ 
solute, relative, or ratio to change its mode. 
Table 2 shows how the mode and value 
determine a note’s delay until release. 
Depending on the mode, the numerical 
value of an articulation shape gives the 
release time of a note, the release time 


relative to the start of the next note, or 
the release time as a multiple of the time 
until the next note. Hence, 

relative 
.1 1.5 111 oseg 

generates a linear transition from stac¬ 
cato to legato over a whole note. This 
articulation shape can be applied to any 
sequence of note durations within that 
period. 

Time deformations. Tempo fluctua¬ 
tions are defined by time deformations 
(TDs). A TD defines a tempo function by 
procedural concatenation. Formula ap¬ 
plies a TD to a time interval X by inte¬ 
grating the tempo function o\erX (start¬ 
ing from the TD’s current position), then 
advancing the position by the duration 
of X. For example, if the tempo varies 
linearly from 1 to 2 over an interval of 
duration 1, the interval is mapped by the 
TD to a duration of 1.5. Figure 11 shows 
a more complex example. 

Figure 12 lists the available TD prim¬ 
itives (others are easy to define). The 
primitives Ipause and rpause insert a 
“pause” in the tempo function; they 
map a single time point to a pause of 
duration /. With Ipause, events (note 
starts or ends) scheduled for this time 
occur after the pause; with rpause, they 
occur before the pause. 

If you attach two TDs to the same 
object, their effects are multiplied. If 
TDs are attached to an object and its 
parent, they are combined in series: The 
output of the first is the input of the 
second. Hence, each object has its own 
“virtual time system,” which is mapped 
to real time by the clusters of time de¬ 
formations attached to it and its con¬ 
taining groups. 

Timing sequence generators. A tim¬ 
ing sequence generator (TSG) is a pro¬ 
cess that generates a sequence of note 
durations for a note-playing process. 
The $ words get note durations from 
TSGs. TSG word definitions are delim¬ 
ited by :sg and ;sg, and embedded TSG 
definitions are delimited by ::sg and ;;sg 
(both constructs add a vocabulary sg- 
defs to the search list). A TSG returns a 
sequence element using 

& (n — ; return a sequence 
element n) 

Table 3 lists commonly occurring 
rhythmic patterns and their naming con- 
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ventions. The words in the table are in 
the sg-defs vocabulary because they are 
called only from TSG definitions. Iden¬ 
tical names are used in the ap-defs vo¬ 
cabulary for words to install a TSG that 
generates an infinite sequence of the 
given durations. This permits convenient 
notation in note-playing processes: 

/4 c d e 3$ 

/8 f g a 3$ 

The first line plays quarter notes; the 
second, eighth notes. 


Two Formula programs 

In this section, we illustrate some of 
Formula’s features using two Formula 
programs. (Readers may order an ac¬ 
companying compact disk or cassette 
tape to hear the two selections we de¬ 
scribe in this section. See the order form 
on page 9.) 

A programmed interpretation. The 

first example is an interpretation of the 
Prelude in F-sharp minor for piano, Opus 
28, No. 8, by Frederic Chopin. Figure 13 
shows the first four measures of the 
score. The specification of the score is 
straightforward because the piece has a 
repetitive rhythmic structure. Like most 
of Chopin’s work, this piece is generally 


seg 

(rl r2 dt 

-; linear tempo change from rl to r2 ov 

er time dt) 

con 

(r dt - - - 

; constant tempo of r over time dt) 


lpause 

(t —; 11 

‘left-justified” pause of duration t) 


rpause 

(t —; ‘ 

‘right-justified” pause of duration t) 



Figure 12. Time deformation primitives. 


Table 2. Determination of a note’s delay until release, D r 


Mode 

Value Determination 

Absolute 

D r = X (does not depend on D n ) 

Relative 

D, = max(0, D n + X) 

Ratio 

D, = XD n 


Table 3. Notation of commonly occurring rhythmic patterns. 


Name 

Definition 

Length of Note 

11 

111 & 

Whole 

14. 

318 & 

Dotted quarter 

14.. 

7116 & 

Double dotted quarter 

2/8 

/8/8 

Two eighths 

/4.8 

14.18 

Dotted quarter and eighth 

12-3 

213 & 213 & 213 & 

Triplet half 

/8+ 

18116116 

Eighth and two 16ths 
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played with significant tempo and vol¬ 
ume fluctuation. 

Figure 14 shows the process structure 
of the program. A top-level group con¬ 
tains note-playing processes for the left- 
and right-hand parts, each of which has 
an articulation shape, a volume shape, 
and a timing sequence generator. Two 
time deformations are attached to the 
group, affecting both note-playing pro¬ 
cesses uniformly. (In some interpretive 
styles, the timing of the left- and right- 
hand parts is deformed independently. 
This is possible in Formula, but it re¬ 
quires writing time deformations that 
synchronize — have equal integrals — 
at the desired points.) 



Figure 14. The process structure of the Formula program for Chopin’s Prelude 
No. 8. Lined boxes show note-playing processes; dashed boxes show auxiliary 
processes. 


1 

:ap rhb (6 pitches — ; do 1 beat of right hand) 

196 :sh lbar (swell over 4 beats, peak on 4) 

2 

dup $ 12 + $ $ $ $ $ dup $ 12 + $ 

197 0 70 314 cseg 

3 

;ap 

198 70 0 114 oseg 

4 


199 ;sh 

5 

:ap rh (right-hand process) 

200 

6 

::shl (volume shape within each beat) 

201 :sh halfbar (swell over 2 beats, peak on 2) 

7 

begin 

202 0 40 114 oseg 

8 

0 1132 ocon -20 1132 ocon 

203 40 0114 oseg 

9 

-40 1116 ocon 

204 ;sh 

10 

-20 1132 ocon -40 1132 ocon 

205 

11 

-10 1132 ocon -201132 ocon 

206 :sh global-volume (long-term volume control) 

12 

again 

207 (1) 2 0 do lbar lbar halfbar halfbar lbar loop 

13 

;;sh 

208 (9) 0 127 611 oseg 127 211 ocon 0 211 ocon 

14 

::ash (articulation control) 

209 (19) lbar 0 127 211 oseg 127 111 ocon 

15 

absolute 

210 (23) 127 0 411 oseg 

16 

begin 

211 (27) 0 111 ocon lbar 

17 

6(32 1132 ocon 5(32 1132 ocon 

212 (29) -40 111 ocon -40 0 314 oseg 0 -40 114 oseg 

18 

1(32118 ocon 

213 (31) -40 100 111 oseg 100 -40 111 oseg 

19 

1(16 1132 ocon 1(32 1132 ocon 

214 (33) 30 211 ocon ;sh 

20 

again 

215 

21 

;;sh 

216 :td tri (n m k — ; triangular TD over 

22 

3 oct 132 

4 beats w/ peak on 3) 

23 

(measure 1) 

217 >r dup >r 112 seg 

24 

2 0 do 

218 r>r>H2seg 

25 

d f+ a b g+ c+ rhb f+ g+ a b g+ c+ rhb 

219 l(641pause (with a little paqse at the end) 

26 

e+ g+ b +c+ a+ f+ rhb g+ b +C+ +d b+ a rhb 

220 ;td 

27 

loop 

221 

28 

(measure 3) 

222 :td tri/2 (n m k — ; triangle over 2 beats) 

29 

+d+ +f+ +a +b +g+ +c+ rhb b+ +d+ +f+ +g+ +e+ +c+ rhb 

223 >r dup >r 114 seg 

30 

+c+ +e +g +a +f+ b rhb a+ +c+ +e +f+ +d+ b rhb 

224 r>r>H4seg 

31 

b +C +d+ +e+ +d a rhb g+ b +d +e +c+ a rhb 

225 1(64 lpause 

32 

e+ g+ b -i-c+ a+ f+ rhb c+ e+ g+ a g d rhb 

226 ;td 

33 

(measure 5) 

227 

228 :td med 310 270 380 tri ;td (some common 

(160 lines omitted) 

rubato patterns) 

229 :td med/2 310 270 380 tri/2 ;td 

194 

;ap 

230 :td slow 320 280 480 tri ;td 

195 


231 :td quick 310 250 310 tri ;td 


Figure 15. Programmed interpretation of Chopin’s Prelude No. 8. 
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Figure 16. A graphic representation of measures 3 and 4 of the Formula program output for Chopin’s Prelude No. 8. 
Each disk represents a note. Horizontal position is time, and the size of the disk represents the note’s volume. The gray 
bar following each disk represents the time for which the note sounds. Vertical lines are ruled at each 32nd note. 


232 

233 :td phrasing-tempo (long term tempo control) 

234 (1) med med med/2 med/2 slow 1(64 lpause 

235 (5) med med med/2 med/2 med 

236 (9) quick quick med/2 med/2 med 1(64 lpause 

237 (13) 300 260 211 seg 1(32 lpause 

238 (15) quick quick 3(32 lpause 

239 (17) med 320 300 600 tri 1(64 lpause 

240 (19) med med 

241 (21) med/2 med/2 300 400 111 seg 1(64 lpause 

242 (23) 400 300 380 tri 380 320 340 tri 

243 (25) 340 280 111 seg 1(64 lpause med 

244 (27) med slow med 320 280 500 tri 1(32 lpause 

245 (31) 300 260 111 seg 1(64 lpause slow 

246 (33) 1(16 lpause 350 500 514 seg 

247 ;td 

L 248 

249 :ap (prelude (main program, synchronous version) 

250 ::gp 

251 96 beats-per-minute 

252 ::gshl global-volume ;;sh 

253 ::gtdl phrasing-tempo ;;td 

1 254 ::gtd2 (rubato at 1 beat level) 

255 begin 270 200 114 seg again 

256 ;;td 

i 257 ::ap $left piano lh ;;ap 

258 $right piano rh 

259 $center 

260 ending 

261 ;;gp 

262 ;ap 
263 

1 264 :ap prelude (main program, asynchronous version) 

265 ::ap” prelude” 

266 (prelude 

267 ;;ap 
268 ;ap 


In the Formula program shown in 
Figure 15, lines 1 through 3 define a 
word rhb to play one beat of the right 
hand. Because each beat contains two 
notes repeated at the octave, we need 
only six pitches to specify the eight notes. 
Lines 6 through 13 define the “micro¬ 
volume” shape for the right-hand part, 
while lines 14 through 21 define the 
articulation shape. The timing sequence 
generator is specified by /32 in line 22. 
Lines 24 through 90 specify the pitches 
for the right hand. Lines 196 through 
214 define a global volume shape ap¬ 
plied to both the left and right hands. 
We separately defined two commonly 
occurring patterns, swells of half- and 
whole-measure duration, with lbar and 
halfbar and used them repeatedly in 
global-volume. 

Lines 216 through 247 define a global 
time deformation for long-term (phrase- 
level) control. This time deformation 
uses a set of words {tri, med, quick, and 
so on) for commonly occurring phras¬ 
ing. Each phrase ends with a short pause. 
A second time deformation is defined 
in-line (line 255) for beat-level control: 
Within each beat, the tempo starts out 
slow and speeds up. Finally, lines 249 
through 268 define the main program. 

Figure 16 graphically represents part 
of the output of this Formula program 
and shows the effects of the auxiliary 
processes described above. The volume 
shapes accent the strong positions with¬ 
in each beat and provide a swell toward 
the high point of each phrase. The time 
deformations (manifested by the irreg¬ 
ularity of the vertical lines) linger on 
the strong beats, rush toward the top of 
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each phrase, and pause between phrases. 
The articulation shape in the right hand 
sustains the melody notes but not the 
passing tones. 

An algorithmic composition. Figure 
17 shows the source code for “Tuf-Stuf,” 
an algorithmic composition programmed 
by Ron Kuivila. The composition dem¬ 
onstrates the power of Formula’s multi¬ 
ple-process model: A short program gen¬ 
erates a lengthy and complex piece. 
“Tuf-Stuf” consists of eight note-play¬ 
ing processes executing the same algo¬ 
rithm ( tuf) but with different parame¬ 
ters (lines 46-53). The algorithm steps 
through a cyclical pitch group with a 
given increment (lines 34-38). For each 
process, the size of the pitch group var¬ 
ies over time. Each process is subjected 
to a triangle wave volume shape (lines 
13-18). The processes start and end at 
different times, and use different in¬ 
strument sounds and spatial locations. 

T he Formula language can 
produce expressive computer¬ 
generated music. It is related to 
music languages such as Moxie, 7 PLA, 8 
Formes, 9 and Darms, 2 but it has a unique 
combination of attributes: 

• Programmability. Almost all Formula 
features are executable statements. Thus, 
the power of the underlying program¬ 
ming language (for example, its control 
structures and parameterized procedures) 
is available throughout Formula. 

•Real-time interaction. Formula is 
based on a real-time process scheduler. 6 
Unless a program’s computation time 
exceeds its performance time over long 
periods, the system executes output ac¬ 
tions with highly accurate timing (typi¬ 
cally within 5 milliseconds). Input-han¬ 
dling processes can very rapidly create 
new note-playing processes, and their 
output begins within a few milliseconds. 

•Lightweight processes. Formula’s 
unit of structure is the process, a thread 
of execution with its own stack of call 
frames and local variables. Processes 
can advance in time within arbitrary 
nested function calls. This is a natural 
and powerful way to maintain computa¬ 
tion state over time. In contrast, lan¬ 
guages such as Moxie 7 require the com¬ 
putation for a given logical instant to 
run to completion. 

• Separation of score and interpreta¬ 
tion. Formula makes it simple to sepa¬ 
rate a score (embodied in note-playing 


and timing-sequence-generator pro¬ 
cesses) from its interpretation (repre¬ 
sented by shapes and time deformations). 

Formula has many other music- 
related features beyond those we dis¬ 
cussed in this article. For example, its 
synthesizer manager provides a uniform 
interface for synthesizer output and al¬ 
lows concurrent processes to share syn¬ 
thesizers coherently. 10 Formula provides 
a facility for defining and using nonstan¬ 
dard tuning systems and includes several 
predefined tuning systems, such as 
“stretched” equal temperament, just- 
intoned scales, and a Javanese Gamelan 
scale. 

Forth’s simplicity and its highly ex¬ 
tensible nature made it well suited for 


developing Formula. On the other hand, 
Forth syntax often leads to hard-to-un- 
derstand code, and it lacks some struc¬ 
turing features (for example, type dec¬ 
larations) useful for large-scale software 
development. For these reasons, we are 
currently reimplementing Formula us¬ 
ing C++ as the base language." ■ 
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1 pquan cycle-size (per-process variables) 

2 pquan base-pitch 

3 pquan inc 

4 

5 :ap tuf (tO tl base-pitch cycle-size inc priority dur shape-dur — ;) 

6 (tO and tl are the start and end times in measures) 

7 (base-pitch is the starting pitch) 

8 (cycle-size determines the size of cycles) 

9 (inc is the increment in cycles) 

10 (priority is the note priority for synth manager) 

11 (dur is the reciprocal of note duration) 

12 (shape-dur is the volume shape period in measures) 

13 ::shl [ 1 params ] (sawtooth-wave volume shape) 

14 >r 

15 begin 

16 p ff r cseg ff p r cseg 

17 again 

18 ;;sh 

19 ::tsg [ 1 params ] (note duration is 1/n) 

20 begin 

21 1 over r>i & 

22 again 

23 ;;sg 

24 ::ash (articulation is detached) 

25 ratio 

26 begin 0.5 111 ocon again 

27 ;;sh 

28 to inc 

29 to cycle-size 

30 to base-pitch 

31 maxtime 


Figure 17. “Tuf-Stuf,” an algorithmic composition by Ron Kuivila. 
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32 time-advance 

33 base-pitch 

34 127 1 do 

35 i cycle-size 2/ * 0 do 

36 inc + j mod base-pitch + 127 and dup $ 

37 loop 

38 loop 

39 drop 

40 maxend 

41 ;ap 

42 

43 :ap (tuf-stuf 

44 ::gp 

45 280 beats-per-minute 

46 ::ap 50 to $location nasty-bass 0 18011 30 2146 2 4211 tuf ;;ap 

47 ::ap 20 to $location piano 1011 18011 50 4 73 4 8411 tuf ;;ap 

48 ::ap 80 to $location piano 2511 5011 66 2 146 3 6411 tuf ;;ap 

49 ::ap 80 to $location piano 5011 18011 66 2 146 3 6411 tuf ;;ap 

50 nap 100 to $location vibes 5011 18011 70 4 73 6 12811 tuf ;;ap 

51 nap 0 to $location xylophone 5011 10011 76 2 146 6 12811 tuf ;;ap 

52 nap 0 to $location xylophone 10011 18011 76 2 146 3 12811 tuf ;;ap 

53 127 to $location electric-piano 10011 18011 69 3 18 9 25611 tuf 

54 ;;gp 

55 ;ap 

56 

57 :ap tuf-stuf 

58 nap” tuf-stuf” 

59 (tuf-stuf 

60 ;;ap 

61 ;ap 
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Recombinant Music 

Using the Computer to Explore Musical Style 


David Cope, University of California, Santa Cruz 


A computer program 
that creates new but 
stylistically 
recognizable music 
from existing works 
offers insights into the 
elusive phenomenon of 
musical style. 


F j or centuries, composers have experimented with recombining existing 
music to create new but stylistically satisfying works. For instance, Haydn 
I and Mozart wrote Musikalisches Wurfelspiel, or musical dice games, pieces 
that could be reassembled in many different ways and remain musically viable. 
Thus, even a very simple piece would become the source of numerous new works, 
each of which, while varying in aesthetic quality, conformed generally to the style 
of the source. 

Mozart’s Kochel 516f is a particularly good example. It consists of two 8 by 11 
matrices containing the numbers 1 through 176 (2 x 8 x 11). The number 8 repre¬ 
sents the measures of eight-bar phrases (traditional classical-period forms), and 
the number 11 represents all possible outcomes of the throws of two dice. These 
numbers are then keyed to 176 measures of music. According to N = D R , where R 
= rank and D = vertical dimension, this allows for 45,949,729,863,572,161 possible 
correct combinations. 

The composers devising these games knew the style of their period intimately 
and applied that knowledge and their own ingenuity to these experiments. The 
word style in this context refers to musical properties characteristic of a particular 
historical-artistic period (in this case, classical), a geographical location (Vienna), 
an instrument (keyboard), and the composer’s personal musical habits (recogniz¬ 
able musical motives, for instance). 

This article delineates some of the elements of musical style I discovered in a 
research project called Experiments in Musical Intelligence (EMI). One subpro¬ 
gram of EMI is an expert system that employs pattern recognition processes to 
create recombinant music — music written in the styles of various composers by 
means of a contextual recombination of elements in the music of those composers. 

This EMI subprogram performs much the same task as the musical dice games 
on music that was not written to be disassembled, reorganized, and reassembled. 
It separates and analyzes musical pitches and durations and then mixes and 
recombines the patterns of those pitches and durations so that, while each new 
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composition is different, it sub¬ 
stantially conforms to the style of 
the original. The new works gen¬ 
erally inherit aspects of the style 
of the period and, to a lesser de¬ 
gree, the style of the composer of 
the recombined works. Called re¬ 
combinant music, this is not just a 
parlor game but a serious attempt 
to understand how listeners rec¬ 
ognize the style of a composer or 
period, one of the more elusive 
and difficult to describe musical 
phenomena. 

The problems 

The fundamental problems in 
building a program to produce 
effective recombinant music are 

(1) into what size should the 
elements of the original music be 
disassembled, 

(2) what method should be used 
to rearrange these elements, and 

(3) how these elements should 
be reassembled to make musical 


After all, random recombination 
produces chaotic results, as shown 
in Figures 1 and 2. Figure 1 pre¬ 
sents two examples of music from 
Mozart’s sonatas. Figure 2 is a ran¬ 
dom recombination of the beats of 
Figure 1, showing the source of 
each reorganized beat by work (A 
or B), measure number, and beat 
number within that measure. 

The new composition is musi¬ 
cal gibberish, as can be seen (and 
heard, if played) in Figure 2. Nei¬ 
ther the common practice of 
Mozart’s period nor his own style 
has survived the recombination. 

One reason for this is that Mozart 
did not compose these phrases as 
a musical dice game. Furthermore, 
the disassembly and recombina¬ 
tion were done unintelligently and 
unmusically. Important questions 
about the size of the musical ele¬ 
ments (one beat in Figure 2) and 
whether harmony and melody 
should be taken together or sepa¬ 
rately were ignored, as was the repeti¬ 
tion of the first two measures of each 
example of Figure 1 (in both cases with 
variation). Nor was attention paid to 
the manner in which the reorganized 



Sonata K. 330, third movement (1778). 



“B” to Figure lb; the numbers represent the location, first by the measure number 
and then by the beat number. 


Audio examples 


Readers may order an accompanying compact disk or cassette tape to hear the 
selections discussed in this article. See the order form on page 9. 
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Figure 3. From Mozart’s Sonata K. 279, First movement (1774). 



signature from (a) K. 330 and (b) K. 
547a. 


material was reconnected. For exam¬ 
ple, the harmonic progressions of Fig¬ 
ures la and lb have been mutilated and 
no longer fit Mozart’s or his period’s 
stylistic constraints. 

Obviously, great care must be 
taken in disassembling the original 
works, analyzing the various constit¬ 
uent parts, and reassembling the parts 
in a new, but musically valid, order. 
The EMI subprogram accomplishes 
this in three steps: 

(1) pattern matching for characteris¬ 
tics of the composer’s style, 

(2) analyzing each component for its 
deep hierarchical musical function, and 

(3) reassembling the parts sensitive¬ 
ly with a technique drawn from natural- 
language processing. 


Pattern matching 

When listening to a piece of music for 
the first time, one usually can detect 
previously heard patterns even though 
the music is generally new to the ears. 
The example in Figure 3 shows how the 
presence of certain patterns can aid in 
style recognition. It demonstrates 
Mozart’s typical use of the Alberti bass, 
the repeated four-note structure in the 
left hand. The right hand demonstrates 
a more subtle trait: the leap to the lower 
chromatic nonharmonic tones C-sharp 
and D-sharp from the second to third 
beats of the first and second measures 
respectively. 

The musical logic of these two pat¬ 
terns (called signatures in EMI), along 
with the harmonic progression and the 
melodic sequence (the second measure 
being a repetition of the first, up one 
step with one subtle variation), com¬ 
bine to create an elegant bit of recogniz¬ 
able Mozartian craftsmanship. The 
constraints of the composer’s period 
and the signatures of his personal style 
are both evident and abundant. 

If a recombinant compositional pro¬ 
cess is to be successful, it must ensure 
that the signatures survive the recon¬ 
structive process in a recognizable form 
and in an appropriate context. There¬ 
fore, the program controlling the disas¬ 
sembly of the original composition must 
determine the appropriate size of the 
signatures as well as recognizing the 
signatures themselves. The recombina¬ 
tion must also be contextually sensitive. 
Signatures must be locationally depen¬ 
dent and immutable to the extent that 
all intervallic relationships remain in¬ 
tact. They must, however, be transpos- 
able so that they reconnect in a variety 
of logical and musical ways. 


The first problem inherent in recom¬ 
binant music, defining a logical sampling 
size, is a complex process. In Mozart’s 
and Haydn’s musical dice games, each 
sample was usually a measure or two 
that began and ended in ways that al¬ 
lowed successful connection with other 
measures in the work. But how long 
should the samples be in the more com¬ 
plex recombinant process undertaken 
by the EMI subprogram described here? 
One way of determining this involves 
pattern matching. 

Musical pattern matching entails the 
discovery of musical patterns, particu¬ 
larly those that occur in more than one 
work of a composer and are hence rec¬ 
ognizable as important elements of the 
composer’s style. This requires a pro¬ 
gram that not only recognizes that two 
patterns are exactly the same, a fairly 
trivial feat, but also that two patterns 
are almost the same. 

The EMI subprogram accomplishes 
musical pattern matching by means of 
controllers that define how closely a 
pattern must resemble another for it to 
register as a match. If we resolve these 
controllers too narrowly, the patterns 
that are one aspect of a composer’s style 
will not pass. If we resolve the controllers 
too broadly, elements that are not patterns 
identifying a composer’s style will be 
allowed to pass. If we set these control¬ 
lers correctly, only signatures will pass. 

Figure 3 shows a simple example of 
pattern matching to find signatures. 
Imagine that these two measures of mu¬ 
sic have been found in two different works 
rather than in the same work and that a 
pattern-matching program is attempting 
to determine whether they constitute a 
signature. It is improbable that a nonmu¬ 
sical pattern matcher would find these 
two measures very similar except in 
rhythm. They share less than 50 percent 
of common pitches (that is, [C C B C E C- 
sharp D] [D C-sharp D F D-sharp E]), 
with none of these falling in the same 
location with respect to associated beats 
within the measures. One measure has 
fewer notes than the other. But to our 
ears, they are easily identifiable as sim¬ 
ple variations of the same pattern. 

What we need is a musical pattern 
matcher that can reduce the patterns to 
similar organizations. The EMI sub¬ 
program does this by reducing pitches 
to intervals. In the first case, the distances 
between notes in the patterns are calcu¬ 
lated in half steps, giving [0-114 -3 1] 
for the first measure and [0-113 -2 1] 
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Figure 5. Some characteristics of the Mozart excerpts shown in Figure 1. 


for the second measure with rests 
represented by zero. Notice that 
the intervals immediately show 
the similarity of the two patterns 
in both direction and amount of 
motion. 

A single controller that deter¬ 
mines interval accuracy proves 
the patterns to be musically alike 
enough to be a signature. By al¬ 
lowing, for example, any interval 
to be off by just one half step in 
either direction, the controller 
enables the program to recognize 
the musical similarity of the pat¬ 
terns. Such a variation, by the 
way, is very common in tonal 
music, where composers, in order 
to remain within a diatonic 
framework when sequencing, of¬ 
ten substitute whole steps for half 
steps and vice versa. Thus, 
lowance for these variations helps 
the pattern matcher find musical 
similarities. 

My research has shown that 
these signatures are typically two 
or more beats in length and occur 
near the ends or cadences of 
musical phrases. They are thus 
locationally dependent and size 
specific. Apparently, most tonal 
composers tended to write more 
freely at the beginnings of 
phrases and to end with style- 
identifying signatures. Figure 4 
shows two versions of a Mozart 
cadential signature with choice of key, 
number of notes, and type of accompa¬ 
niment as variations. The intervallic 
movement of the melodies of both ex¬ 
amples is exactly the same, with varia¬ 
tions in the rhythm. The harmony is 
likewise the same functionally, although 
there are discrepancies in the voicing 
and doubling. 

Figure 5 shows two complete phrases 
from the same Mozart sonatas given in 
Figure 1, with signatures shown in boxes. 
The harmonic signatures are labeled “S,” 
with “AM” standing for accompaniment 
motives and “MM” for melodic motives. 
The latter two matching elements com¬ 
prise a pattern-matching subprogram that 
gives the analysis portion of the program 
information about the dominating me¬ 
lodic and accompaniment models. Ob¬ 
serve that the cadential signature in Fig¬ 
ure 5b is the one shown in Figure 4a and 
that the melodic part of the signature in 
Figure 5a resembles the melodies shown 
in Figure 4. 


The two musical examples shown in 
Figure 5 (that is, the music of Figure 1) 
have very much in common. This is crit¬ 
ical to the pattern-matching process just 
described. The compositions chosen for 
EMI must be reasonably similar, in¬ 
cluding key and meter. The last catego¬ 
ry is particularly important. For exam¬ 
ple, imagine a single work written first 
in quarter notes with the metronome 
set at the quarter note equal to 60 (one 
quarter note per second) and then re¬ 
written in eighth notes with the metro¬ 
nome set at the quarter note equal to 30 
(one eighth note per second). Perfor¬ 
mances of both pieces would sound the 
same. Yet, they would look and analyze 
very differently, particularly if the pro¬ 
gram being used assumed certain beat 
constraints were in effect. Thus, entered 
music must be coerced to look the same, 
in both musical and numerical nota¬ 
tions. 

Once EMI discovers signatures, it 
freezes them to their location and then 


protects them during recomposition. 
Without this protection, signatures 
would get lost in a Pandora’s box of 
confused musical ideas. Once signatures 
are frozen, the remainder of the music is 
fragmented fairly freely in size, since at 
this stage the idea is to create a new 
instance of the composer’s style, with 
the original works being unrecogniz¬ 
able. 

Hierarchical analysis 

Successful recombinant music must 
retain the musical logic inherent in the 
original works upon which it is based. 
Therefore, the program at this point 
analyzes all the musical groupings, in¬ 
cluding signatures, for hierarchical 
function. In the initial stages, this anal¬ 
ysis is a traditional analysis of harmonic 
function, using functional categories 
theorists call “tonic” or I (C triad in C 
major), “dominant” or Y (G triad in C 
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major), and so on. The analysis is made 
prior to the mixing of groupings, be¬ 
cause the protocol, or ordering of func¬ 
tions, is critical to the reorganizing of 
groupings. When mixing does take place, 
it follows the form of a fixed sequence 
of functions with free substitution of 
the actual music the functions repre¬ 
sent. Thus, the tonic function remains 
in the same location in the new work, 
but it can exchange music with other 
analyzed music of that same function 
(that is, other tonics). Again, signatures 
do not move nor can they be replaced. 

The hierarchical analysis can be quite 
deep. That is, fragments can be keyed 
by strata of information, such as 
“cadence-tonic” or “tonic-6-incipient,” 
which indicate the original location and 
nuance of function. With a large num¬ 
ber of works for analysis, the program 
can choose from hundreds of different 
categories, each with numerous musi¬ 
cal subphrases, so that successive parts 
of the new work can be musically tied 
together and not just randomly cho¬ 
sen. 

The program also must analyze the 
original works for proper connective¬ 
ness before the elements of the music 
are fragmented and mixed. This analy¬ 
sis falls into three main categories: 

• melody 

• accompaniment 

• harmony 

Rising melodies, for example, can be 
followed by falling ones for balance. 
Accompaniments, which otherwise 
would be a pastiche of various motives, 
can be made rhythmically consistent so 
that they flow regularly with the me¬ 
lodic line. Harmonies can be success¬ 
fully juxtaposed according to the tradi¬ 
tions of the tonal common practice. 
Harmonic analysis includes measuring 
the strength of chord functions so that 
stronger cadences can be saved for the 
last chord of new works. This measure¬ 
ment also produces contextual connec¬ 
tivity so that each fragment is spliced 
into a logical location. 

We can see how EMI’s hierarchical 
analysis works by analyzing the various 
beats in Figures 5a and 5b and per¬ 
forming some basic steps to enhance 
the relationships. Both of these sonatas 
begin on a tonic chord that can be in¬ 
terchanged successfully with the appli¬ 
cation of musical transposition to the 
left hand (that is, moving Figure 5b, 


measure 1, up one octave). Figure 5a, 
measure 1, beats 3 and 4 are dominant 
in function and either could be substi¬ 
tuted for the dominant of Figure 5b, 
measure 2, beat 2, with no ill effects and 
no transposition necessary. Likewise, 
the first two beats of Figure 5a, measure 
1, could be interchanged with the first 
two beats of measure 1 of Figure 5b with 
no damage. On the other hand, taking 
the second bar of Figure 5b and inter¬ 
changing it with the first two beats of 
Figure 5a would cause serious problems. 
Not only do the functions not match, 
but beginning the work on an unprepared 
dissonance would be stylistically un¬ 
characteristic. 

Also notice in Figures 5a and 5b that 
the program separates harmony (accom¬ 
paniment) from melody with nonsigna¬ 
tures. The separation occurs after the 
hierarchical function analysis, howev¬ 
er, so that melodic groupings retain their 
harmonic implications. This is very im¬ 
portant for the reassembling process. 

Since music often contains structural 
repeats at various levels, analysis of the 
substructural repeats in the original mu¬ 
sic must occur at this point in the process. 
For this analysis, the EMI program uses 
a pattern matcher similar to the one de¬ 
scribed earlier but with a different func¬ 
tion. This pattern matcher informs the 
reassembly part of the program as to 
where internal (to the phrase) repeats 
take place so that similar repeats can 
take place in the final output. 

Once all elements of the music have 
been analyzed, harmonic functions of 
the same type are stored together in 
lexicons and randomly mixed (the 
shaking of the dice). Access to each 
lexicon is then controlled by the 
functional succession of one of the 
original works, as described in the 
next section. 

Reassembling 
according to the ATN 

The refitting of juxtaposed elements 
of a work back into logical and musical 
orders can be enhanced by using aug¬ 
mented transition networks (ATNs), a 
technique developed by researchers in 
natural-language processing. ATNs are 
programs designed to produce logical 
sentences from sentence bits and pieces 
that have been stored according to 
sentence function. These parts are reused 


to produce correct sentences in various 
forms with basically the same meaning. 
For example, “The prognosis for Jill is 
good” and “Jill has an excellent possi¬ 
bility of recovery” say the same thing in 
different ways. ATNs are typically used 
in computer applications in which vari¬ 
ation in the form, but not the substance, 
of the output (for example, medical 
prognosis) facilitates communication. 
ATNs can be applied to the recombinant 
music problem in much the same way as 
to language: analyze and store musical 
elements and then reuse them in com¬ 
positions that vary but have essentially 
the same musical meaning (variations 
within a set style). 

In EMI, the ATN initially takes the 
form of an organizer. It first takes the 
set of functions from the analysis of one 
of the works being used. For example, 
one possible analysis of the first three 
beats of Figure la is “tonic-Alberti- 
repeat, tonic-6-Alberti-repeat, dominant- 
Alberti-up,” and so on. The ATN then 
uses this analysis as a template for cre¬ 
ating a new work by gathering applica¬ 
ble groupings of music from collections 
stored previously by the analysis por¬ 
tion of the program. For example, ex¬ 
actly the same “tonic-Alberti-repeat” 
given above could be logically chosen. 
The chance of that happening obviously 
depends on the amount of analyzed 
music available—the larger the amount, 
the greater the chance for variety. This 
process is very similar to the ATN lan¬ 
guage model upon which the EMI sub¬ 
program is based. 

When the organizing is complete, 
EMI’s ATN then becomes a smoother 
of transitions. Musical lines that previ¬ 
ously had been stepwise must again be 
made so. The ATN does this by diatonic 
transposition. In layman’s terms, the 
ATN fixes the positions of the notes 
according to the key of the work in as 
close a proximity to those that precede 
and follow them as was found by the 
analysis of the original works. For Mozart 
this proximity is seconds and thirds. Ac¬ 
companiment figures usually adapt by 
octave transposition to fit the local range 
of the music, since the type of figure is 
determined by the setting of the function 
types (for example, the use of Alberti in 
the naming and storing of hierarchical 
function). In addition, melodies and 
harmonies previously located elsewhere 
may require refitting so that they don’t 
overlap in range or uncharacteristically 
fall out of proximity. 
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Figure 6. EMI’s recombination of segments in Figure 5, with signature (B7.1) and 
suggested sources (t = transposition; v = variation). 



Combining the concepts of pat¬ 
tern matching, hierarchical anal¬ 
ysis, and ATN gives us a process 
that can create new examples of a 
given style. Figure 6 shows a ma¬ 
chine replication with one possi¬ 
ble analysis of this replication (the 
program itself is sufficiently com¬ 
plicated to make the determina¬ 
tion of the origins of these seg¬ 
ments in the original music difficult 
at best). Note that the music here 
is logical and even musical to a 
degree. The opening motive seems 
balanced by direction, with the 
two two-beat groupings in the 
melody of the first measure act¬ 
ing in typical classical-period an¬ 
tecedent-consequent motions. 

The cadential signature is a real 
signal of Mozart’s style. In typical fash¬ 
ion, it is just over two beats in length. 
Transposition is fairly routine, while vari¬ 
ation is used only sparingly. The repeti¬ 
tion of bar 1 in bar 3 contributes to stylis¬ 
tic recognition. This EMI subprogram 
achieves such repetition by means of the 
previously discussed analysis of the orig¬ 
inal music, which indicates how much 
repetition should occur in the output. 

The signature presented in Figure 3, 
that of the lower chromatic neighboring 
tone, appears transposed in the recom¬ 
binant example shown in Figure 7, mea¬ 
sures 2 and 4, an EMI-composed theme. 
This example is sparse (two voices) and 
simple (mostly scales). Yet, it has many 
Mozartian traits. For example, the har¬ 
monic rhythm moves by measure. The 
harmonic functions follow a straightfor¬ 
ward I-V-V-I-I-ii-V-I order typical of 
Mozart’s style. 

The music shown in Figure 7, the re¬ 
sult of EMI pattern matching, hierarchi¬ 
cal analysis, and ATN recombination of 
all the Mozart sonata third movements, 
demonstrates the composer’s subtle 
implied harmonies and voicing. By the 
time all the computational processes have 
taken place, it is virtually impossible, 
save for the obvious signatures, to abso¬ 
lutely identify the origin of each ele¬ 
ment. I prescribed the form (that is, the 
amount and location of phrase repeti¬ 
tion and contrast), and the key choice 
was random. However, the important 
ideas, signatures, and the harmonic pro¬ 
tocol were formed completely by the 
recombinant processes described here. 


M usical style is a very compli¬ 
cated phenomenon. Recog¬ 
nizing a particular style is 
linked, at least in part, to the presence 
of fundamental musical signatures in a 
composer’s work. Reusing such signa¬ 


tures, while sensitively reorganizing oth¬ 
er elements of the music, allows for the 
creation of new music with recogniz¬ 
ably the same style as the original. Sim¬ 
ilar experiments with the music of Bach, 
Joplin, Chopin, Gershwin, and many 
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others seem to verify the results reported here (see Cope, 
1991, in the “Further reading” section). 

Works produced by this EMI subprogram still suffer from 
problems of stylistic anomalies. Future research will aim at 
eliminating such anomalies by enhancing the hierarchical anal¬ 
ysis program. In addition, dynamics and phrasing will become 
a part of the matching processes, refining the program substan¬ 
tially. If EMI has been moderately successful at creating new 
music in established styles, it is due in no small part to the music 
incorporated for recombination. In short, EMI has had great 
teachers: the classical masters themselves. ■ 
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Toward an Expert 
System for Expressive 
Musical Performance 


Margaret L. Johnson, Stanford University 


An expert system 
processes the melodies 
of Bach fugues using a 
model that recognizes 
rhythmic patterns. 

It outputs instructions 
that tell performers 
how to articulate 
the melodies. 


M ; usical expert systems have been developed for composition, harmonic 
S analysis, education, and performance. For performance, expert system 
offerings range from real-time accompaniment 12 to performance rules that 
can serve as the basis for a computer performer. Sundberg, Askenfelt, and Fryden 3 
defined “pronunciation rules” that differentiate a notated piece of music from the 
performed version. These rules concern duration, pitch, frequency, and amplitude. 
The authors derived the rules using a musical synthesis-by-rule approach. 

Katayose and Inokuchi 4 described a robotic system that generates performance data 
from a score by applying rules — based on style analysis — that describe how to play. 

The research I present in this article differs from previous research because the 
rules in the knowledge base were derived from elicitation interviews with per¬ 
formance experts. 

Project description 

I developed and implemented an expert system that determines the tempo and 
articulations of Bach fugues. Tempo is an indication of how fast or slow to play the 
piece. Articulation denotes clarity and distinct rendition in a musical performance. 

The rules in the knowledge base I developed are based on the expertise of two 
professional performers. In describing my system, I use the term rule to mean a 
guide for behavior. 

The system’s input is a numeric representation of the fugue. The system 
processes the input using a transition graph, which is a data structure consisting of 
nodes where data is stored and edges that connect the nodes. The transition graph 
recognizes rhythmic patterns in the input. Once the system identifies a pattern, it 
applies a specific rule or performs a procedure. System output consists of a listing 
of tempo and articulation instructions. 


The music 

The pieces of music I selected for this project are the fugues in 4/4 time from Bach’s 
Well-Tempered Clavier, Book 1: Fugues 1-3, 5, 7-9,12,13,16-18,20,23, 24. 
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A fugue is a polyphonic composition 
for a set number of voices built on a 
single theme called the fugue subject. 
The subject enters in one voice, is imi¬ 
tated in another voice (the imitation is 
called the answer), enters in a third, and 
so on, until each voice has stated the 
subject. At frequent intervals through¬ 
out the fugue, the subject or answer 
appears in one voice or another, in re¬ 
lated keys. The subject or answer can be 
accompanied by another melody called 
the countersubj ect. In between the state¬ 
ments of the main melodies are epi¬ 
sodes, which are variations or develop¬ 
ments of a part of the subject. 5 

I limited my implementation to fugues 
with 4/4 time because my knowledge 
elicitation revealed that meter strongly 
affects articulation. Thus, I would have 
to elicit a different set of rules for fugues 
with a meter of 3/4 or 6/8.1 chose fugues 
because they develop very systematically 
and are thus easier to analyze than free¬ 
form pieces. For the performance me¬ 
dium, I chose the harpsichord because 
Bach used this instrument. In addition, 
the harpsichord has only one level of 
loudness, so the possible articulations 
are limited and my task was simpler. 


Knowledge elicitation 

I used two experts in this project, Bob 
James and Anthony Newman. Bob 
James is a prominent jazz composer and 
performer. Anthony Newman is a well- 
known keyboard performer. James 
supplied general expertise on interpre¬ 
tative decision making, while Newman 
filled in the details for the particular 
pieces with which I worked. I elicited 
the expertise from 

• interviews, 

• a performance practice manual, 6 and 

•an edition of the Well-Tempered 

Clavier by Anthony Newman. 7 

This expertise consisted of a strategy 
for making interpretative decisions and 
a series of specific rules on how to set 
the tempo and articulate the melodies 
of a Bach fugue. 


Knowledge 

formalization 

I used Klir’s concept of knowledge 
structures 8 to formalize the elicited 


Ornaments: trill mordent 
Articulation markings: 

Tenuto: Lengthen the note’s duration by a 32nd note. 

Staccato: Shorten the note’s sounding duration by one half. 

Slur: Play the slurred notes legato, that is, without any perceptible 

interruption between the notes, 

MM J = x: This expression indicates tempo according to the Maelzel 
metronome: A piece marked MM quarter note = 80 indicates that the 
tempo should be set so that there are 80 quarter notes per minute. 

Figure 1. Definitions for a vocabulary of performance. 



Figure 2. Numeric representation using half steps. 


knowledge. Klir’s four knowledge struc¬ 
tures, which are invariant across disci¬ 
plines, are 

• source, the vocabulary of domain- 
specific words; 

• data, the examples of the domain; 

• behavior, the rules of the domain; 
and 

• structure, the context for the other 
three knowledge structures. 

Klir’s concept can be applied rigor¬ 
ously or mathematically, 9 but I used it 
simply as a guide to organize the elicit¬ 
ed knowledge. The first step was to 
define the contents of each knowledge 
structure for the domain. 

Source. In my musical expert system, 
the source is a vocabulary of perfor¬ 
mance: the words and symbols used to 
communicate tempo and articulation. I 
limited the description to the harpsi¬ 
chord performance of the subset of B ach 
fugues listed in the section above enti¬ 
tled “The music.” Figure 1 lists the def¬ 
initions, which derive from the software 
I used to generate audio examples. 

Data. Data are examples that can be 
recorded or measured. A person listen¬ 
ing to music is hearing data. Therefore, 
we have data when the performance is 
complete. 

Behavior. There are three levels of 
behavior for a performer: 


(1) The musical 
score itself 
as Bach 
composed it. 

(2) The original 
music of 
Bach en¬ 
hanced with 
the articula¬ 
tions and tempo instructions as 
Anthony Newman would add 
them. 

(3) The rules and procedures that 
guide the performer in deciding 
on tempo and articulations. 

I represented the first level of behav¬ 
ior using a numeric code that provides 
the melodic and rhythmic input for the 
expert system. A melodic pattern can 
be represented numerically using half 
steps. For example, Figure 2 shows how 
the subject from Fugue 2 from the Well- 
Tempered Clavier can be represented. 

In the figure, 0 is the starting note. 
The other numbers indicate the number 
of half steps away from the starting 
point each note is, and a positive or 
negative sign indicates the direction (up 
or down) from the starting note. 

I specified the rhythmic values of notes 
and rests in terms of 24 units per quarter 
note. Thus, a 32nd note or rest is repre¬ 
sented by 3, a 16th note or rest, 6; an 
eighth note or rest, 12; a quarter note or 
rest, 24; a half note or rest, 48; and a 
whole note or rest, 96. 

An output listing of tempo and articu¬ 
lation instructions constitutes the second 
level of behavior, and the third level 
consists of general rules that guide the 
performer. Figure 3 gives a partial listing 
of the 28 tempo and articulation rules. 

In situations where more than one 
rule applies, procedures analyze addi¬ 
tional information and select the appro¬ 
priate rule. For example, procedure 2 
decides among rule 3, rule 4, and rule 5 
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Tempo 1: If the fastest note value is a 16th note and the meter is 4/4, 
then the tempo is MM quarter note = 80. 

Tempo 2: If the fastest note value is an eighth note and the meter is 4/4, 
then the tempo is MM quarter note = 85. 

Rule 1: If the subject opens with a group of eight 16th notes or 32nd 
notes, then slur the group of eight notes together. 

Rule 2: If a series of more than two quarter notes is in the subject, 
then play the quarter notes tenuto. 

Rule 3: If the fugue is in a major key, begins with a rest, then has three 
stepwise eighth notes, then play the eighth notes tenuto. 

Rule 4: If the fugue is in a major key, begins with a rest, then has three 
leaping eighth notes, then play the eighth notes staccato. 

Rule 5: If the fugue is in a minor key, begins with a rest, then has a 

series of three eighth notes, then play the eighth notes tenuto. 

Rule 24: If thereis a group of three or seven 16th notes following a rest, 
then slur the 16th notes following the rest. 

Rule 25: If the final note of the subject or answer is on beat 1 of a 
measure, then include this last note in the next sequence. 

Rule 26: If there is any group of 16th notes following a tied note, then 
slur the group of 16th notes following the long note. 

Figure 3. Tempo and articulation rules. 


(a) 0 -1 

0 -5-4 0 -1 

0 2 -5 

0 -1 ... 

(b) -1 

1 -5 1 4 -1 

1 2-7 

5 -1 


Figure 4. Melodic pattern (a) and half-step pattern (b). 


on the basis of the key of the fugue and 
whether a series consisting of a rest and 
three eighth notes is stepwise or not. 

Structure. The form or plan of the 
piece is its structure. A fugue has a very 
specific structure consisting of repeti¬ 
tion and development of one single 
theme or parts of that theme. There¬ 
fore, in structure I place a map of the 
fugue showing where the main melodies 
appear in the piece. The structure is 
important in performance because each 
time the subject, answer, or counter¬ 
subject is stated, the performer should 
articulate it the same way. Therefore, 
the expert system processes these mel¬ 
odies only once, skipping over them 
when it encounters them later. 

Knowledge 
representation and 
implementation 

To implement the four knowledge 
structures for the test subset in an ex¬ 
pert system, I analyzed an expert’s strat¬ 


egy for using them. Conceptually, Bob 
James starts in structure by analyzing 
the fugue for the main melodies. Then, 
he goes to behavior and begins process¬ 
ing the first set of notes. He goes from 
Bach’s score to the set of rules to see if 
one applies. He then edits the score 
with his articulations based on the rules. 
From here, he may go to data to test the 
articulation by performing it. Then he 
returns to behavior to process the next 
set of notes. 

Overview. The basis of my imple¬ 
mentation is emulation of the expert’s 
strategy in making interpretative deci¬ 
sions. The expert begins by analyzing 
the piece and determining its structure. 
My system does the same using a pro¬ 
gram that analyzes the numeric nota¬ 
tion to define the main melodies. 

Analysis program. The first step of 
the analysis is to define the pattern of 
half steps between successive notes. 
Since a subject, answer, or countersub¬ 
ject can be stated in different keys, the 
analysis program cannot use exact notes 
to find the patterns; it needs the half¬ 


step patterns. Therefore, it first sub¬ 
tracts the numeric value of each note 
from each previous note. For example, 
Figure 4 shows the melodic and half¬ 
step patterns of the subject of Fugue 2 in 
C minor. 

The program uses the number of half 
steps between successive notes for pat¬ 
tern matching to find the melody inde¬ 
pendent of key. It deals with answers as 
separate melodies, not as variants of the 
subject. It locates the subject, answer, 
and countersubject by pattern match¬ 
ing on the database containing the nu¬ 
meric representation. 

Transition graph. Once the analysis is 
complete, the system’s next step is to 
make articulation decisions. A transi¬ 
tion graph for rhythmic patterns directs 
the system’s movements. Figure 5 shows 
an example. The nodes of the graph 
contain the rules or procedures that 
apply if the system stops on that node 
while processing the notes. The edges 
of the graph contain rhythmic values. 

System processing starts at the initial 
node (Start) and moves along the edge 
that matches the rhythmic value of the 
processed note. The system arrives at a 
node and then looks at the rhythmic 
value of the next note. If the value of the 
next note matches the value on the out¬ 
going edge, the system proceeds to the 
next node. This continues until the 
rhythm of the next note does not match 
the value on the outgoing edge. Then 
the system applies the node’s contents, 
which is a rule or a procedure. 

For example, consider the rhythmic 
pattern of a rest followed by three 16th 
notes and an eighth note. The system 
begins at the Start node and follows the 
99 (Rest) edge to an empty node (in the 
numeric code, 99 denotes a rest). The 
rhythmic value of the next note is 6, so 
the system follows the outgoing edge to 
the next node. It passes the next two 
empty nodes because the rhythmic val¬ 
ue for each of the next two notes is 6. At 
this point, it is at the node labeled R24. 
The next rhythmic value is 12 (an eighth 
note). This does not match the value on 
the outgoing edge, so the system stops 
and applies rule 24: If there is a group of 
three or seven 16th notes following a 
rest, then slur the 16th notes following 
the rest. 

The program outputs a list of instruc¬ 
tions. Figure 6 shows the output for part 
of the subject of Fugue 2. The complete 
listing (not shown here) includes the 
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Bar Beat 

Message 


Base tempo: MM quarter note = 80; 

Opening: 

Slur the two 16th notes together. 

1 2 

Subject: Play both eighth notes staccato. 

1 3 

Subject: Prolong the downbeat note slightly. 

1 3 

Subject: Slur the two 16th notes together. 

1 4 

Subject: Play both eighth notes staccato. 

2 1 

Subject: Prolong the downbeat note slightly. 


Figure 6. Partial listing of performance instructions generated by the expert sys¬ 
tem. 


entire fugue, not just the articulation of 
the main melodies. (The sidebar below 
explains how to obtain a recording that 
demonstrates the effect of output in¬ 
structions on a performance.) The tran¬ 
sition graph works for all parts of the 
melodies, including the episodes. 

Validation 

To validate the expert system, I com¬ 
pared its output with the edited ver¬ 
sions of fugues in Anthony Newman’s 
edition of the Well-Tempered Clavier. 1 
In tests with six fugues, the expert sys¬ 
tem generated the same editing instruc¬ 
tions 85 to 90 percent of the time. Fur¬ 
ther validation could consist of 
Newman’s reviewing the instructions and 
the rules for completeness. 


F uture work with the system in¬ 
cludes expanding it to analyze 
and output instructions for other 
fugues from the Well-Tempered Clavier 
as well as nonfugal pieces. To accom¬ 
modate the variety of meters used in the 
Well-Tempered Clavier, I am eliciting 
new transition graphs and rule sets for 
each meter and enhancing the system to 
handle them. These enhancements 
should handle all the fugues in the Well- 
Tempered Clavier, as well as most other 
Bach fugues. 

I will use the music of other compos¬ 
ers with rhythmic characteristics simi¬ 
lar to those of Bach’s music to see wheth¬ 
er the system can go beyond Bach’s 
works. Nonfugal pieces will probably 
require a different representation of the 


Audio examples 

Audio examples that demonstrate 
the effect of the articulation instruc¬ 
tions on a performance are available 
on CD or cassette. They consist of 
three fugue subjects played first with 
no articulations, and then with the ar¬ 
ticulations added as instructed by the 
output listing. (The examples were 
generated using Music Printer Plus by 
Temporal Acuity Products.) The audio 
examples are the subjects from 
Fugues 2, 13, and 7. The recording 
also includes an entire performance of 
Fugue 2 based on the output instruc¬ 
tions. See order form on page 9. 


knowledge, because currently the en¬ 
tire expert system is geared to the prob¬ 
lems of fugue articulation. 

How close are we to giving a perform¬ 
er all the instructions needed for an 
expressive performance? A human per¬ 
former brings to a performance not only 
a set of rules on how to articulate the 
music properly. He or she also brings 
the music alive by communicating the 
composer’s message. This goes beyond 
a simple application of rules. The per¬ 
former’s personality and temperament 
are also expressed in the performance. 

In this project Ihave not implement¬ 


ed a complete automated performer. I 
have found a method of eliciting, for¬ 
malizing, and representing the rules that 
one expert uses to determine articula¬ 
tions of Bach fugues. I have not tried to 
add the personal element that a human 
performer brings to the music. 

Would there be any value in enhanc¬ 
ing the system to include such human 
elements? The value depends on the 
purpose. If we want a truly expressive 
“human-sounding” performance, we 
probably should have a human perform 
the music. However, eliciting and for¬ 
malizing the expertise needed to create 
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Take on Today’s 
Biggest Challenges in 
Advanced Computer 
Systems Development. 

This opportunity isn’t for just anyone. We’re looking 
for MS or PhD graduates in Electrical or Computer 
Engineering, or Computer Science, to join us at our 
Engineering and Manufacturing facility in Columbia, 
South Carolina. 

NCR will give you every opportunity to prove your¬ 
self defining, developing and prototyping advanced 
engineering concepts, and building systems from the top 
down. You’ll employ both theoretical and empirical 
methods to direct engineers in the design of new com¬ 
puter system architectures. These include our famed 
TOWER family and the System 3550, a symmetric, 
tightly-coupled multiprocessor system designed to 
deliver 80 to 320 MIPs, based on the NCR SVR4/ 
MP-RAS operating system. The System 3550 is a key 
component of the newly announced System 3000 family 
of scalable computer systems. You’ll also get involved 
with furthering architectural modeling techniques, I/O 
subsystem design and multiprocessor issues. 

In addition to your academic credentials, you must 
be able to provide technical leadership to NCR, and to 
the industry overall through publications and work with 
various industry-wide technical organizations. A broad 
understanding of computer system architecture and 
detailed knowledge of and experience in one of the follow¬ 
ing areas are absolutely essential: state-of-the-art GUI- 
based systems administration and operations manage¬ 
ment, distributed operating systems, I/O systems, 
CPU/memory design, multiprocessors, UNIX* kernel, 
compilers for parallel computers, cache coherency 
models, networks, behavior or performance modeling, 
and development of continuously available systems. 

At NCR, we recognize and reward valuable contribu¬ 
tions with a competitive salary, outstanding benefits and 
the varied attractions of South Carolina’s state capital, 

homeoftheUniversityofSouthCarolina. Forconfidential 

consideration, please send resume and salary history to: 

Personnel Resources, Dept. 55G 
NCR Corporation 
3325 Platt Springs Road 
West Columbia, SC 29170 

An equal opportunity employer. 
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Open, Cooperative Computing. 
The Strategy for Managing Change. 

*A Registered Trademark of AT&T 


a truly expressive performance might teach us a great deal 
about the nature of human performance. Whether such ex¬ 
pertise can be represented and implemented in an expert 
system remains open to future research. ■ 
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Fugue: 

A Functional Language 
for Sound Synthesis 


Roger B. Dannenberg, Carnegie Mellon University 
Christopher Lee Fraley, Microsoft Corporation 
Peter Velikonja, West Virginia University 


Fugue provides 
functions to create and 
manipulate sounds as 
abstract, immutable 
objects. The interactive 
language supports 
behavioral abstraction, 
so composers can 
manage complex 
musical structures. 


T raditional software synthesis systems — which include Music V, 1 cmusic, 2 
and Csound 3 — are based on the same principles. Composers use a score 
language to describe a list of notes or sounds to be synthesized. Each note 
specifies a starting time, a duration, an instrument name, and a list of parameters 
specific to the instrument (such as pitch, loudness, and articulation). A separate 
orchestra language defines a set of instruments, each of which specifies a particular 
signal processing algorithm. An instrument is defined as a set of interconnected 
signal processing steps known as unit generators. Typical unit generators are 
oscillators, filters, adders, and multipliers. 


Each note in the score language invokes an instance (essentially a copy) of an 
instrument in the orchestra. This instrument instance computes sound for the 
duration of the note according to the parameters of the note statement. The 
synthesis system adds the resulting sound to that of the other notes in the score and 
writes them all to a disk file. After the computation completes, the system can read 
the synthesized music from the disk in real time and convert it into analog form for 
listening. 

This approach has been used without much change for over two decades. It 
offers excellent and robust ideas, but it also has some weaknesses. An obvious 
problem is the separation of the score and orchestra languages. 

In this article, we present Fugue. Unlike the traditional approach, which re¬ 
quires separate languages for different tasks, Fugue lets composers express signal 
processing algorithms for sound synthesis, musical scores, and higher level musical 
procedures all in one language. 

Although it extends the traditional sound synthesis approach 2 with concepts 
borrowed from functional programming, 4 Fugue retains the advantages of the 
Music V class of systems. One advantage of Music V is that composers can specify 
the starting time and duration of each note in the score. These temporal attributes 


36 


8-9162/91/0700-0036S01.00© : 


COMPUTER 








are implicit parameters to each instru¬ 
ment instance that tell the system when 
to start and how many samples to com¬ 
pute. Fugue supports an extension of 
this technique. 

Another important contribution of 
Music V is the notion of combining unit 
generators into a signal flow graph. 
Fugue implements this feature effi¬ 
ciently. 

Programs as scores 

Historically, musical scores have been 
static data structures created by com¬ 
posers. Traditional scores do not ex¬ 
press computation beyond a few simple 
abbreviations to indicate repeats or al¬ 
ternate endings. There is a good reason 
for this. Traditional scores are data in¬ 
tensive and contain much detailed in¬ 
formation because composers want to 
express the results of their creativity, 
rather than show the process of cre¬ 
ation. 

Consequently, lists of notes and their 
attributes have been the standard form 
of machine-readable scores for many 
years. As data structures, note lists can 
be transformed in time, in pitch, or 
along any other dimension defined by 
note attributes. It is generally easier to 
generate and manipulate data struc¬ 
tures than programs. For example, 
making all the notes in a section louder 
is easy if the notes are represented as 
data. But note lists can suffer from the 
fact that they are not programs. In par¬ 
ticular, there is a schism between the 
“score” and the “orchestra”: The score 
controls while the orchestra executes; 
the functions are not integrated. 

A common way to address this di¬ 
lemma is to use programs to compute 
note lists. This presents at least two 
problems. Composers must deal with 
yet another language (as if two were 
not enough), and the ultimate result 
does not close the gap between the 
score and orchestra. For example, note¬ 
generating procedures cannot use the 
results of signal processing functions in 
the orchestra, and instruments in the 
orchestra cannot call on the note-gen¬ 
erating capabilities of the score. 

Fugue offers a new approach. Fugue 
scores are actually program expressions 
that, when evaluated, return audio or 
control signals. Fugue also defines in¬ 
struments in terms of expressions that 
denote audio signals. Thus, composers 


can use one language for both instru¬ 
ments and scores. 

With this unification, composers can 
express scores and instruments more 
flexibly. In traditional synthesis systems, 
it is difficult to alter a phrase of many 
notes by a single volume envelope, be¬ 
cause this requires a hierarchical nest¬ 
ing of notes within the volume envelope. 
In Fugue, however, scores and signals 
are all nested expressions, making hi¬ 
erarchical structures very natural. 

Composers can also use Fugue for 
signal analysis to determine aspects of a 
score. Signal analysis is a common 
practice in computer music, but signal 
analysis programs are rarely integrated 
into traditional sound synthesis lan¬ 
guages. 

Perhaps Fugue’s most valuable feature 
is that it encourages composers to de¬ 
velop personal musical vocabularies, 
unencumbered by a language-specified 
model of how music or music computa¬ 
tion should be structured. Of course, 
any language, including Fugue, is bound 
to influence how composers approach 
programming or composition. Howev¬ 
er, Fugue supports the Music V model 
of computation as a subset, so we can at 
least claim an improvement in flexibil¬ 
ity and generality. 

Fugue allows the composer to treat 
simple instruments and sounds as 
building blocks for more complex sound 
events. This development process is 
supported by its abstraction capabilities 
and an interactive language interpreter. 


Behavioral abstraction 

An important feature of Music V is 
that note starting times and durations 
determine when and how long the sys¬ 
tem instantiates an instrument. In ad¬ 
dition to unifying the score and orchestra, 
Fugue also supports this approach. 
Otherwise, temporal aspects of com¬ 
positions might be very difficult to ex¬ 
press. 

Starting times and durations in Music 
V provide a special kind of abstraction: 
Instruments define a class of behaviors 
that can have any starting time or du¬ 
ration. Abstraction is important because 
it is not always obvious what to do to 
make a note longer. For example, a 
violinist typically lengthens a note by 
drawing the bow across the string for a 
longer period of time, but if the note is 
a tremolo, with rapid back-and-forth 


bowing, the violinist adds more bow 
strokes to extend the duration. Clearly, 
the notion of stretching is abstract, and 
the software instrument designer must 
control its implementation. The user of 
the instrument, however, need not be 
aware of the implementation details. 

To support nested expressions in 
Fugue, we viewed a starting time or 
duration as a transformation rather than 
as an absolute parameter. We extended 
the concept to allow transformations of 
articulation, loudness, and pitch. Com¬ 
posers can make additional qualities 
transformable and extend the system 
with new transformation operators. 

Programmers or composers define 
behaviors that describe how to generate 
a sound within a transformation context. 
A context in Fugue reflects the cumula¬ 
tive effect of nested transformations on 
environmental parameters such as cur¬ 
rent time, stretch, transposition, and 
overall loudness. Behaviors can be hi¬ 
erarchical compositions of other behav¬ 
iors. Once defined, a behavior can have 
many instances, each of which can be 
evaluated in a different context and/or 
with different parameters. In this way, 
composers can define concepts such as 
“drum roll” or “glissando” once and 
apply them in many different contexts. 

A behavior realized according to a 
context is called a behavioral ab¬ 
straction. 5 We present a few examples 
to show how Fugue uses behavioral 
abstractions. In a sequence of three 
sounds 

(seq (tremolo A3) (cue wind) (osc Bf3)) 

cue is a behavior that simply plays a 
sound at a given time, and tremolo and 
osc play pitches (A and B-flat below 
middle C). Osc and cue are built-in be¬ 
haviors, while tremolo is defined by the 
composer in terms of built-in behaviors. 
Wind is a sound, perhaps loaded from a 
sound file. 

If we want to hear the same sequence 
half as loud and with the wind sound 
delayed by 2 seconds, we write 

(loud 0.5 

(seq (tremolo A3) (at 2.0 (cue wind)) 
(osc Bf3))) 

Suppose we wish to change the pitched 
sounds of the sequence. We write 

(transpose 3 (seq (tremolo A3) 

(cue wind) (osc Bf3))) 
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Figure 1. Page 25 from the score of Spomin. To generate the score, we replaced 
Fugue’s sound generation modules with modules that output graphics com¬ 
mands. The modules ensure that the score accurately reflects the sound. The fi¬ 
nal score shown here includes manually added music symbols. 


This says to transpose the sequence up 
by three semitones. However, the cue 
abstraction overrides and prevents the 
transposition of wind because cue is 
intended for use with unpitched sounds. 
Hence, only the tremolo and osc behav¬ 
iors are affected. We could replace cue 
with a behavior that would allow the 
wind sound to transpose. 

In general, we defined transforma¬ 
tions and built-in behaviors to work 
like traditional unit generators. As a 
result, most instrument definitions in 
Fugue support the standard transfor¬ 
mations implicitly. But composers can 
always customize the default behavior 
as needed. 


An example 

The composition Spomin (an unpub¬ 
lished score by P. Velikonja) uses thou¬ 
sands of transformations of a single 
human vocal utterance (see the box at 
right). The composer used Fugue sound¬ 
processing primitives to manipulate the 
source sound to varying degrees, so some 
sounds are clearly vocal while other 
more highly processed sounds bear lit¬ 
tle relation to their vocal source. Using 
Fugue, the composer extracted slices of 
the source, in some cases down to the 
level of an individual period. Once ex¬ 
tracted, a period can be cycled to form a 


sustained tone (as in the technique used 
by sampling synthesizers). Quickly 
swapping periods during this cycling 
produces a tone with a time-varying 
spectrum, a technique used extensively 
in the latter half of the piece. In the first 
half, the composer used tones generat¬ 
ed from extracted periods to create 
chords, glissandi, and chorus effects. 

Spomin illustrates the advantage of 
using an integrated language for ex¬ 
pressing score information as well as 
signal processing. Composers can dele¬ 
gate signal processing routines to low- 
level functions and then work more ab¬ 
stractly using high-level functions. 
Moreover, Fugue modules, modified to 
output printing information rather than 
digital samples, can produce the graph¬ 
ical portion of a score. Figure 1 gives an 
example. 

The code in Figure 2 shows the layer¬ 
ing of several levels of abstraction. In 
this example a short slice is cut from the 
source sound and cycled to form a grain. 
Grains of sound form pebbles, which 
are strung on a necklace. The second 
band from the top in Figure 1 shows 
necklaces modified at the grain level to 
rise in pitch over time. Each grain is 
represented by a short line, angled to 
indicate where (in the source) a slice 
was extracted. The third, fourth, and 
fifth bands show timing and amplitude 
information. The top band shows glis¬ 
sandi of tones built from extracted peri¬ 
ods. 

Without Fugue’s abstraction capabil¬ 
ities and computational support, the top 
level of the score would consist of many 
thousands of notes, each corresponding 
to a tiny grain of sound. Such a score is 
technically feasible but impractical to 
construct or edit by hand. 

Because Fugue allows composers to 
combine components to form complex 
structures, they can control large sound 
events with a few commands. The inter¬ 
active environment provides rapid 


Audio examples 

Readers may order an accompa¬ 
nying CD or cassette to hear the 
selections discussed in this article 
by using the order form on page 9. 
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feedback, so composers have greater 
control over sound materials. Fugue’s 
supportive framework helps composers 
explore new musical forms and compo¬ 
sitional methods. Composers can define 
a musical syntax so that they can com¬ 
pose music as a process rather than as a 
simple series of notes. Some might ob¬ 
ject that Lisp is too great an obstacle for 
noncomputer scientists, so it is worth 
mentioning that Spomin is the first full 
piece generated using Fugue and was 
the composer’s first exposure to Lisp. 

Implementation 

We implemented Fugue in a combi¬ 
nation of C and XLisp to run on Unix 
workstations. (Written by David Betz, 
XLisp is an interpreter which is in turn 
implemented in C.) We used XLisp 
because it is fairly easy to extend with 
new data types, and it is also easy to 
interface with C programs for signal 
processing. Lisp provides convenient 
and powerful interaction, and C effi¬ 
ciently implements low-level function¬ 
ality. It might be possible to use a more 
efficient compiled Lisp. However, most 
of the computation time is taken by 
signal processing primitives, so the Lisp 
interpretation represents only a small 
overhead. 

We implemented Fugue’s transfor¬ 
mation context in Lisp. Operators such 
as Transpose are macros that bind an 
element of the context (*Transpose* in 
this case) and then evaluate the em¬ 
bedded expression. The binding is re¬ 
stored upon exit from the transforma¬ 
tion. Composers can introduce new 
synthesis techniques into Fugue by 
combining existing behaviors or by 
writing new sound synthesis algorithms 
in C and calling them from Lisp. 

Our implementation includes multi¬ 
ple sample rates and lazy evaluation to 
increase time and memory efficiency. 
Multiple sample rates allow for “con¬ 
trol” signals at a low sample rate, as in 
the Music-11 system and Csound, 3 re¬ 
ducing time and memory requirements. 
When the system must manipulate two 
sounds with different sample rates, it 
uses linear interpolation by default to 
resample the lower sample rate signal 
to the higher sample rate. Composers 
can explicitly specify other types of in¬ 
terpolation. Because there is no distinc¬ 
tion between control and audio signals, 
composers can use filters to modify Spec- 


(defun osc-slice 

;a slice from time start 

(sound sndpitch start end pitch dur) ; 

;to end is cut from 

(s-mult (pwl (* dur .5) 1.0 dur) 

,sound, oscillated at 

(osc pitch dur 0 

pitch with an 

(extract start end sound) 

envelope of length dur. 

sndpitch))) 


(defun bb-grain (period pitch dur) 

a grain consists of one such 

(osc-slice bb 49.0 

oscillated slice. A grain 

(* period 0.008) 

is selected by the number 

(+ 0.008 (* period 0.008)) 

period. The typical 

pitch 

length of a slice is 0.008 

dur)) 

seconds. 

(defun bb-pebble 

;a pebble is formed from 

(ngrains period pitch dur) 

;several ( ngrains) grains. 

(seqrep (g ngrains) 

;In this example the grains 

(bb-grain (+ period g) pitch dur))) 

;between period and 


period + ngrains form 


;the pebble. 

(defun bb-necklace 

a necklace is made from a 

(npebbles ngrains pitch dur) 

number ( npebbles ) of 

(seqrep (p npebbles) 

pebbles. 

(bb-pebble ngrains p pitch dur))) 


(sf-od 

;a necklace made from 8 

(s-mult 

;pebbles, each containing 90 

(pwl 25.01.0 28.0.5 35.0) 

•.grains of 0.05 second 

(bb-necklace 8 ; npebbles 

;duration pitched at e2 

90 ; ngrains 

;(tenth above middle c), has 

76.0 ; pitch 

;a piecewise-linear envelope 

.05 ; dur 

;applied to it. The sound is 

))) 

;written (by sf-od) to an 


;optical disk. 


Figure 2. An example Fugue program taken from Spomin, showing multiple 
levels of abstraction. Any level can be invoked interactively for testing, or from 
within a higher level expression serving as a score. 


tra or to smooth envelopes, and use 
multiplication uniformly for gain con¬ 
trol, amplitude envelopes, or audio-rate 
amplitude modulation. 

We implemented sounds in Fugue as 
an extension to Lisp. Sounds are im¬ 
mutable values, meaning that once a 
composer creates a sound, it cannot be 
altered. Therefore, the implementation 
cannot add several sounds directly into 
a single buffer. Instead, each addition 
of two sounds produces a new sound. 
Using lazy evaluation, 6 we avoid the 
inefficiency of immutable values. When 
composers perform additions (and 
many other operations), our implemen¬ 
tation merely builds a small data struc¬ 
ture describing the desired operation. 


Fugue doesn’t actually compute any 
samples until absolutely necessary, and 
when it does, it can combine opera¬ 
tions. For example, Fugue commonly 
allocates only one array to hold the 
result of many additions. This tech¬ 
nique avoids many needless copy oper¬ 
ations and is completely hidden from 
the composer. 

Example of lazy 
evaluation 

To demonstrate how Fugue’s imple¬ 
mentation of lazy evaluation works, we 
show what memory structures look like 
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(setf Mysound (sfload “mysound”)) 

(setf Demo (scale 2.0 (seq (cue Mysound) 

(cue Mysound)))) 

(play Demo) 


Figure 3. Sequence of operations for the lazy evaluation example. 


Mysound 


\ _ 

Scale 1.0 

JK From 0.0 sec. 

I To 1.0 sec. 

End 1.0 sec. 

iSj Shift 0.0 sec. 

Stretch 1.0 

SRate 16 kHz 


I Samples for "mysound"! 


Figure 4. Memory structure of My¬ 
sound after the first operation in Fig¬ 
ure 3, assuming the duration of My¬ 
sound is 1 second. The system loaded 
the samples from a file. 



Figure 5. Memory structure of Demo after the second operation in Figure 3. 
The transformations and summation are reflected in the data structure, so the 
system doesn’t need to compute new sound samples. 


at each step of a sequence of operations. 
Figure 3 shows the operations. The first 
line sets the variable Mysound to a sound 
stored in the file “mysound.” Figure 4 
shows the resulting configuration. The 
second line evaluates a score consisting 
of two copies of Mysound in sequence. 
Because only time-shifting and addi¬ 


tion are involved, essentially no compu¬ 
tation takes place. Figure 5 shows the 
resulting configuration. The system has 
performed no addition; instead, Fugue 
represents the sum as a data structure. 
Finally, the third line forces the system 
to produce samples for Demo. It replac¬ 
es the representation for Demo with 


one in which the actual samples have 
been computed and storage for samples 
has been allocated, as shown in Figure 
6. This last step is the only time the 
system allocates new storage for sample 
data and actually computes a new sound 
sample. 

Imagine a typical computation of the 
form 

for i := 1 to 100 do 

myPiece := myPiece + 
MakeNote(i); 

In Fugue, a roughly equivalent program 
would be 

(seqrep (i 100) (make-note i)) 

where seqrep is a control construct that 
concatenates some number of instances 
of a behavior — in this case 100 copies 
of make-note. 

Typically, MakeNote(i) generates a 
relatively short signal to be added to a 
much longer myPiece. Without lazy 
evaluation, each addition requires the 
system to 

(1) allocate memory at least the size 
of myPiece to hold the sum of the 
two signals, 

(2) copy myPiece into the new mem¬ 
ory area, and 

(3) add the result of MakeNote to 
form the new signal. 

Allocating memory and copying signals 
make this computation costly. 

With lazy evaluation, each “lazy” ad¬ 
dition simply adds another level to a 
tree of sum nodes like the one in Figure 
5. To produce the final result, the sys¬ 
tem traverses the tree to determine the 
size of the result, allocates memory, and 
adds the leaves of the summation tree. 
This technique eliminates memory allo¬ 
cation and signal copying to form inter¬ 
mediate results. 

We considered but did not implement 
another approach for efficient execution. 
In the alternate approach, the composer 
explicitly allocates a buffer to hold the 
final sum of the MakeNote signals, and 
the system allows the buffer to be modi¬ 
fied by an add-signal operation. This 
approach violates the principle that sig¬ 
nals are immutable, and it places more 
storage management burden on the com¬ 
poser. Lazy evaluation, on the other hand, 
allows Fugue to exhibit clean and simple 
semantics without loss of efficiency. 


40 


COMPUTER 








































Future directions 


References 


We need to extend Fugue with more 
sound functions as in Moore’s cmusic 
(distributed by the University of Califor¬ 
nia at San Diego), Vercoe’s Csound (dis¬ 
tributed by the MIT Media Lab), Next’s 
Sound Kit, 7 and Lansky’s Cmix (distrib¬ 
uted by the Princeton University Music 
Department). These systems are popu¬ 
lar partly because of the library of syn¬ 
thesis techniques they provide. 

We may investigate the use of Fugue 
in parallel computation. Because of its 
functional style, Fugue programs con¬ 
tain explicit parallelism in the sim (“si¬ 
multaneous”) construct. Even when 
there are data dependencies such as in 
the seq construct, lazy evaluation often 
defers signal computations so that the 
data dependencies can be resolved im¬ 
mediately. Then the signal processing 
can proceed in parallel. If we implement 
sounds in Fugue as streams, we can 
achieve even more parallelism by lazily 
evaluating streams. This could dramat¬ 
ically reduce the memory requirements 
for intermediate results in Fugue ex¬ 
pressions. Even with large virtual mem¬ 
ories and automatic garbage collection, 
storage is a serious problem in the cur¬ 
rent implementation. 

An exciting potential of the lazy eval¬ 
uation of streams is real-time execu¬ 
tion. 8 This would require real-time 
garbage collection as well. We have not 
yet explored many opportunities for the 
compilation and optimization of Fugue 
behaviors. 


M any of the ideas we use in 
Fugue seem appropriate for 
computer graphics and com¬ 
puter animation. The idea of behavioral 
abstraction seems to fit nicely with graph¬ 
ical transformations (for example, 
“make this truck longer”) and also with 
action in animations (“run faster”). In 
computer animation, Fugue’s notions 
of explicit timing and constructs for 
parallel and sequential behavior might 
be useful. For images, new constructs 
might be added to represent spatial as 
well as temporal relationships. 

We could extend Fugue’s semantics 
in several ways. Currently, only some¬ 
one with a fair understanding of how 
contexts are implemented can extend 
the context in Fugue. We should make 


Demo 



Figure 6. Memory structure of Demo 
after the third operation in Figure 3. 
The system computes samples accord¬ 
ing to the transformations in Figure 5 
and caches the resulting samples, re¬ 
placing the previous data structure 
with a new one. 


this simpler. Fugue should also sup¬ 
port the use of MIDI (musical instru¬ 
ment digital interface) files as scores 
so that composers can use existing 
music editors as data sources. Another 
improvement would be to allow 
time-varying transformations, 9 using 
signals in place of real numbers to 
achieve musical effects such as accele¬ 
rando (gradual increase in overall tem¬ 
po) and crescendo (gradual increase in 
overall loudness). Also, Fugue must 
support multidimensional signals. We 
plan to make these changes in a future 
version. ■ 
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f A Computer Music 
System that Follows 
a Human Conductor 

Hideyuki Morita, Shuji Hashimoto, and Sadamu Ohteru 
Waseda University 


An electronic orchestra 
with a complex 
performance database 
and MIDI controllers 
responds to the 
gestures of a conductor 
through a CCD camera 
and a sensor glove. 


T n 1981, we developed a computer vision system that could read musical 

■ scores. We implemented it in the keyboard-playing robot Wabot-2, which 
acquired external information about music in real time through computer 
vision. 1 ’ 2 However, Wabot-2 was not adaptable enough to play with human musi¬ 
cians because the musical score it read contained only part of the information 
needed to perform a piece of music. 

Fortunately, a number of advancements now aid the acquisition of musical 
information. MIDI (Musical Instrument Digital Interface) instruments controlled 
by a computer can be quite effective in modern musical performances (see 
sidebar). Although most early systems sounded just like old-fashioned mechanical 
music boxes, MIDI automatic electronic performance systems now generate a 
great variety of sounds and tonalities. 

To respond to external music information, modern systems must acquire it 
directly through sensory perception. The system must have the equivalents of 
sight, hearing, and intelligence so that it can cooperate in real time in an ensemble 
performance or in automated accompaniment. These capabilities are even more 
important should the system conduct, rather than just accompany, the musical 
group. 

Mathews 3 worked with conductors to build an early conducting system based on 
the Groove program using knob inputs (two mounted four-toggle, push-button 
sensing switches) as early as 1979. In 1984, Dannenberg 4 and Vercoe 5 each 
implemented an automated accompaniment system that followed a soloist. Ac¬ 
cording to a conversation with Vercoe, M. Puckette of the Massachusetts Institute 
of Technology demonstrated an early conducting system that used two sonar 
sensors. 

Recent methods to control performance use special input devices and have 
achieved noteworthy results. 6 ’ 7 However, these systems have peculiar modes of 
operation. Musicians find them difficult to use because special knowledge and 
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skills are needed. However, there is another way to direct 
musical performance without using both musical instruments 
and voice, as previously required. 

Through a conductor’s gestures, human performers who 
share a common knowledge of conducting receive a type of 
intelligent communication. A conductor directing an orches¬ 
tra, a chorus, or an opera can convey complex emotions to 
many musicians simultaneously. We have developed an elec¬ 
tronic orchestra that responds to the gestures of a human 
conductor. In doing so, we faced some specific challenges. 
For instance, not all conducting is clear. Also, most conduc¬ 
tors have a very individual technique. Consequently, we 
adapted a common set of basic rules called the grammar of 
conducting (Figure 1) to process human gestures. We have 
introduced the term conducting as a body of knowledge 
I common to both the human and the automatic performance 
system. 


A musical bus 

MIDI (Musical Instrument Digital Interface) has been 
standardized to mutually convey real-time musical perfor¬ 
mance information between electronic musical instru¬ 
ments. The MIDI standard defines hardware (transmitter, 
receiver) and data formats. 1 A state is expressed by the 
“message,” which divides into a channel message and a 
system message. The former includes the MIDI channel. 
Each musical instrument is optionally allotted a channel. 
For example, the piano uses channel 1, the flute channel 
2, and so on up to 16 channels. The system message is 
the common message shared by the whole system. 

Reference 

1. MIDI Specification 1.0, International MIDI Association, Los 
Angeles, 1983. 



Processing musical information 

Information about musical performance is basic to the 
development of an automatic electronic system. This infor¬ 
mation falls into two general categories: basic and musical 
performance expression (Mpx). The former type of static 
information, which consists of quantifiable symbols, is indis¬ 
pensable to playing a piece of music. Mpx information, which 
is subjective and dynamic, helps the performer create the 
artistic essence of the performance. When the computer 
processes a musical performance, it must distinguish between 
these two kinds of information to effectively simulate human 


Figure 1. Basic conducting techniques: the four-beat trajec¬ 
tory (a); the four-beat sharp trajectory (b); and the four- 
beat smooth trajectory (c). 8 
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Table 1. Examples of musical 
performance information. 


Basic 

Musical Performance 


Expression 

Notes 

Crescendo 

Pitch 

Ritardando 

Frequency 

Sostenuto 

Duration 

Dolce 


performance. But since interpretation 
of the Mpx information is complex and 
does not follow precise rules, it is diffi¬ 
cult for the computer to handle it direct¬ 
ly. (See Table 1.) 

Consider a human player in an or¬ 
chestra (Figure 2). The player acquires 
basic music information and Mpx score 
information through the score. The 
musician then adds Mpx conducting in¬ 
formation while playing under the con¬ 
ductor’s direction. In repeating the per¬ 
formance, the musician usually improves 
technique, knowledge, and the musical 
sense. Mpx historical information re¬ 
lates to how this music was played in the 
past by incorporating Mpx score and 
conducting information and Mpx per¬ 


sonal information that results from an¬ 
alyzing previous performances. The fi¬ 
nal Mpx information is determined from 
all Mpx information available for a par¬ 
ticular situation. 

Since Mpx information is hierarchi¬ 
cal, it must be interpreted at different 
levels. Two kinds of knowledge are nec¬ 
essary. One is the educational or text 
knowledge that provides the musical 
common sense mentioned in the text¬ 
books. The other is the experiential 
knowledge that results from the artistic 
playing experience. 

Furthermore, a performance is 
planned, carried out, and evaluated by 
the conductor, the audience, other per¬ 
formers, and each musician. A musician 
empirically acquires knowledge by ob¬ 
jectifying a continuous stream of evalu¬ 
ation and feedback. 

We are trying to re-create this entire 
process on a computer, that is, to build 
a computer-controlled process that can 
do the same things human beings can. 

System outline 

Figure 3 is a flow diagram of the sys¬ 
tem. MIDI score data has previously 
been stored in the MIDI sequencer as 
basic music information. The conduc¬ 


tor’s right-hand motion is perceived and 
interpreted by the baton motion-com¬ 
prehension system and the left-hand 
motion by the gesture-comprehension 
system operating in parallel. 

The conducting field is the limited 
area that transmits the right-hand ba¬ 
ton conducting motion to a CCD 
(charge-coupled device) camera view¬ 
er. The delicate movements of the left 
hand and the bending of those finger 
joints — both essential to conducting — 
are perceived with the Data Glove pro¬ 
duced by VPL Research. 

Mpx conducting information is ex¬ 
tracted by analyzing the conductor’s 
motion with the aid of a knowledge 
database of conducting. 

Mpx conducting information extract¬ 
ed from the motion of both hands is sent 
to the performance system, which syn¬ 
thesizes final Mpx information from the 
preliminary score, historical, and con¬ 
ducting information. 

The MIDI instrument controllers — 
the synchronization signal controller and 
the programmable signal processor — 
add their reactions to the MIDI score 
data. 

Thus, performance data in MIDI form 
controls the MIDI instruments in real 
time so that they can perform under the 
direction of a human conductor. 
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System operation 

Our system has two main parts: ges¬ 
ticulation and MIDI instrument con¬ 
trollers. 


Gesticulation. This system perceives 
and interprets conducting and other 
human-communication gestures in real 
time. We have opened up a new channel 
in the human-machine interface by us¬ 
ing gestures that have always played an 


important role in human communica¬ 
tion. We believe that the best way to 
analyze the conductor’s gestures or 
emotional expressions is through a three- 
channel gesture analyzer consisting of 
magnetic and optical fiber sensors and a 



July 1991 


47 
















































































Figure 4. Baton trajectory with constant (a) and changing (b) tempo and 
strength. 



Figure 5. Prediction and compensation method for tempo: an example of the 
response (a); and formulas (b). 



video camera. The overall system for 
comprehending conductor gestures con¬ 
sists of baton-motion comprehension, 
gesture comprehension, and perfor¬ 
mance communication. 

Baton motion. Every 1/30 of a second, 
the feature extraction hardware pro¬ 
cesses a 256 x 256-pixel input image of 
the CCD camera with an infrared filter. 
The process extracts the trajectory of 
the infrared light (5 millimeters across) 
attached to the tip of the baton and 
sends the x-y coordinate to the comput¬ 
er. (Due to the use of infrared light, the 
conductor may not wear a costume that 
glitters.) A conventional 16-bit micro¬ 
computer processes and interprets the 
baton’s movement. 

We consulted a professional conduc¬ 
tor about the relationship between the 
movements of the baton and the con¬ 
ductor’s intentions. We then analyzed 
the data in detail from the standpoint of 
image processing. We found the nota¬ 
tions x„ y, (trajectory), A x„ A y, (veloc¬ 
ity), and A 2 x,, A 2 y, (acceleration) of the 
baton to aid the system’s comprehen¬ 
sion. We can extract the parameters 
needed for accurate high-speed com¬ 
munication from human to computer. 
This system follows the conductor’s 
baton using a CCD camera with the aid 
of real-time image-processing hardware 
and a database of conducting knowl¬ 
edge. 

The conductor sets the tempo by beat¬ 
ing the baton. Depending on the meth¬ 
od of conducting, the beat point is given 
by the vertical reversal point of the ba¬ 
ton motion. Figure 4 shows how the 
system detects this point. The half-beat 
period T separates the beat points at the 
top of the trajectory from the back beat 
points at the bottom. 

Figure 5 shows the method of predic¬ 
tion and compensation. A delay or ad¬ 
vance time is gradually recovered dur¬ 
ing the following half beat. This sounds 
more natural than an immediate adjust¬ 
ment. As the results of our fundamental 
analysis, we found that the plot of A 2 y, 
changes a great deal when the conduc¬ 
tor indicates a sudden change in tempo 
(Figure 6). We think that the conductor 
helps the performers foresee the com¬ 
ing change of tempo by a slight change 
of the force that governs the baton 
motion. In fact, A 2 y, at the beat point 
changes a 2 times, and a tempo becomes 
a times. 
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Table 2. Mpx information recognized in the baton-motion comprehension 
system. 


Mpx Information 

Point of Recognition 

Legato, accent 

Value Q of A 2 y in the beat point 


Go = A 2 y 0 /2Af 0 

Tenuto, staccato 

A X t / A y t 

Time or rhythm 

Figure of baton’s trajectory 

Volume 

Integral of baton’s path length 



Figure 7. Total path length of the ba¬ 
ton. 


t - t 

h -~7= 7 o 

y a o 


( 1 ) 


where a, equals acceleration at the beat 
point and 7) a beat period. 

The system can predict the next tem¬ 
po using Formula 1 even when the tem¬ 
po changes suddenly. 

Strength can be recognized by mea¬ 
suring the total path length Dxy along 
the upper and lower reversal points of 
the baton (Figure 7). 

The rhythm can be recognized by 
measuring the distance between a beat 
point and the previous beat points (Ta¬ 
ble 2). We are striving to add the follow¬ 
ing expressions, which can be perceived 
and interpreted to the MIDI score data. 
Legato and accent processes are recog¬ 
nized using the value Q of A 2 y at the 
beat point (Figure 6), while tenuto and 
staccato are recognized by using the 
sharpness of the plane trajectory at the 
beat point. 

Gesture comprehension. A true user- 
friendly interface would introduce non¬ 
verbal communication that everyone 
could understand. But high-speed pro¬ 
cessing of an image moving in three 
dimensions is very difficult, even with a 
video camera. The Data Glove (Figure 
8), however, has an optical fiber sensor 
and a magnetic position sensor that al¬ 
low real-time analysis of the delicate 
three-dimensional movements of the 
hand and finger joints. The glove plays 
an active part in the research field of 
VR (virtual reality). A 32-bit micro¬ 
computer has analyzed the left-hand 



Table 3. Values of movement-pattern vector S = (S„, S v ..., S „). 


Value 

Description 

So 

Vertical position 

Si 

Horizontal position 

s 2 

Sum of five previous values of a vertical velocity 

S3 

Sum of five previous values of a horizontal velocity 

s 4 

Sum of five absolute previous values of a vertical velocity 

s 5 

Sum of five absolute previous values of a horizontal 
velocity 

s 6 

Crooking of the thumb ([first joint] + [second joint]) 

s 7 

Crooking of the index finger ([first joint] + [second joint]) 

S 8 

Crooking of the middle finger ([first joint] + [second joint]) 

s 9 

Rotation of the palm 

Sjo 

Facing of the palm (up, down) 
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position and finger crooking according 
to the grammar of conducting. 

At first, a user inputs the limits of a 
left-hand position (up, down, right, and 
left), its velocity (vertical or horizon¬ 
tal), and its finger curvature (grasping 
or straight), so that the conductor’s phy¬ 
sique does not influence the analysis of 
the motion. 

The computer quantifies the move¬ 
ment data from the Data Glove relative 
to these limits to produce a movement- 
pattern vector S = (S 0 , S v ..., S n ). This 
vector consists of the 11 values shown in 
Table 3 on page 49. 

The meaning function table RT ex¬ 
presses the relationship between the 
movement-pattern vector S and the 
meaning vector C. The table for con¬ 
ducting (Figure 9) is made up before¬ 
hand. The user can change the contents 
of this table as required by inputting 
motions with special meanings to cor¬ 
rect a table or make up a new one. 

The meaning C can be determined 
with the help of the meaning function 
table by the following formula: 

C, = Z RTyiS,) (2) 

If the maximum value C of the meaning 
Cj is over a predetermined threshold 
value, the computer comprehends that 
the user is indicating the meaning C. If 
the meaning C that includes the value 
pianissimo is judged, for example, the 
computer evaluates the value from the 
motion and sends it to the performance 
system with the meaning. 

When a conductor wants to control a 
certain instrument section, he or she 
points to the supposed positions of the 
musical instruments before indicating 
the meaning C (Figure 10). Consequent¬ 
ly, the conductor can direct, for exam¬ 
ple, the oboe to intensify the volume or 
the violin and cello sections to use a 
vibrato (see Figure 11). Of course, no 
particular selection means that all in¬ 
struments are selected. 

Performance communication. This 
system synthesizes and integrates final 
Mpx information. The information it 
provides is a blend of the score, histor¬ 
ical, and conducting information accord¬ 
ing to the reference weights W set by the 
conductor (Figure 12). Furthermore, 
Figure 9. Examples of recognition in the gesture-comprehension system: move- because Mpx information divides into 
ment-pattern vector graph (a); meaning-function table (b). three levels (emotional, expressive, and 
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Gesture: Pointing to the virtual position of the 
oboe 

Expression: The oboe 
Parametric: MIDI channel No. 8 


Gesture: The straight index finger on the mouth 
Expression: Pianissimo 
Parametric: Volume down 50% 

MIDI commands: Control change message No. 7 
(the present value) /2 in MIDI channel No. 8 


Figure 10. Selecting the instrument section. Figure 11. Instrument selection pro¬ 

cess. 


parametric), the performance system 
has to interpret these. The system can 
learn, for example, three interpreta¬ 
tions of dolce by a conductor and select 
legato and mezzo piano (see Table 4). 
After a performance, the system inputs 
the conductor’s evaluation of the inter¬ 
pretation. 

The conductor instructs the system 
by indicating with the baton or the Data 
Glove a value from good to bad on a 
continuous scale. If the conductor, for 
example, indicates “very good,” the 
weight value is heightened. Afterwards, 
the system selects its interpretation ac¬ 
cording to these weight values. 

MIDI instrument controllers. Our sys¬ 
tem can play MIDI instruments using a 
sequencer synchronized with an exter¬ 
nal MIDI or FSK (frequency-shift key¬ 
ing) clock signal. Two more devices are 
needed for it to mix the basic music 
information in MIDI format with the 
final Mpx information. We developed 
these devices especially for computer- 
MIDI processing. One is the synchroni¬ 
zation signal controller, which gener¬ 
ates a variable-period clock sequence 
used for the external synchronization 
of the MIDI sequencer. The period is 
adjusted quickly according to the tem¬ 
po information received from the per¬ 
formance system. The other is the pro¬ 
grammable MIDI signal processor 
(using an 8-bit, one-chip microcomput¬ 
er), which, using the Mpx information 
from the performance system, can re¬ 
write the MIDI velocity value or insert 
a control change message instantaneous¬ 
ly in the instrument channel that has 



Figure 12. Information processing in the performance system. 

Table 4. Three interpretations of dolce. 


Emotional 

Expressive 

Weight Value 

Dolce 

Type A: Legato and mezzo piano 
Type B: Portamento and piano 
Type C: Vibrato and mezzo forte 

y 

z {x+y + z = 1) 
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Table 5. Messages inserted by programmable MIDI signal controller. 


Performance Parameter 

Message 

Volume 

Control change No. 7 

Vibrato 

Control change No. 1 

Portamento 

Control change No. 5 

Expressivo 

Control change No. 11 

Hold (damper) 

Control change No. 64 

Timbre change 

Program change 


been selected by the conductor (see 
Table 5). The MIDI standard, inciden¬ 
tally, is not suitable for distinguishing 
Mpx information from basic music in¬ 
formation, because the MIDI standard¬ 
ized to transmit performance informa¬ 
tion in real time has no conception of 
the beat nor any descriptive rule for the 
expression marks. Therefore, our per¬ 
formance controller controls the 
progress of the music by counting vari¬ 
able-period clock pulses — say, 48, 96, 
or 144 clocks to a beat. In this way, it can 
also grasp the correct position on the 
score even when the tempo has sudden¬ 
ly changed. The MIDI basic music data 
can be correlated to the Mpx informa¬ 
tion we have developed. 

Human interface 

A conducting system, by definition, 
must provide a friendly human inter¬ 
face. 


Supervision by the performance com¬ 
munication system. This system pro¬ 
cesses not only musical information but 
also human-interface information such 
as a system and human setup for each 
user. Thus, from the beginning of the 
setting of the score data in the MIDI 
sequencer to the end, a user can set up 
the system without using the computer 
keyboard. Instead, the user can employ 
the baton or the Data Glove in dialogue 
with the computer. When displaying 
explanations, questions, or answers, the 
computer can simultaneously repeat 
these messages with its voice synthesiz¬ 
er. With these messages, a user can 
operate the system even if unfamiliar 
with the computer. For example, one 
way to reply to the computer is to move 
the baton to a predetermined area in 
virtual space (Figure 13). The perfor¬ 
mance system will recognize the start of 
the performance when the baton is in a 
predetermined position, and if the ba¬ 
ton disappears or is stationary for a 


time, it will stop temporarily and ask 
the conductor, “Will you continue to 
conduct?” 

The effects of misdetection and of 
involuntary slight trembling of the con¬ 
ductor’s hand are also eliminated. The 
conductor sets the amplitude thresh¬ 
old for such trembling by shaking the 
baton in front of the camera as in¬ 
structed by the computer. 

Stability and sensitivity. For perfor¬ 
mance control, we have to consider the 
trade-off between stability and sensi¬ 
tivity in the tempo response. From “the 
extra beat” that a conductor inserts 
into a constant tempo just before con¬ 
ducting a score, the computer evalu¬ 
ates not only the initial tempo but also 
the conductor’s steadiness or exacti¬ 
tude. This exactitude is used as the rate 
of the modification in the prediction 
method. Consequently, sensitivity is 
enhanced for an “exact” conductor, and 
stability is enhanced for an inexact con¬ 
ductor. Since the tempo of a perfor¬ 
mance changes whenever the tempo of 
inexact conducting changes slightly, in¬ 
voluntary fluctuation of the tempo in¬ 
fluences the performance. This effect 
sounds more natural than “computer 
music” quantified to eliminate such fluc¬ 
tuations. 

Results 

The first professional conductor who 
tried our system could direct it without 
special skills or knowledge of either 



Audio examples 

Those of you who have the CD or audiocassette pro¬ 
duced with this issue may listen to the following project 
examples: 

(1) Symphony No. 1, (J. Brahms), live recording; 

(2) “Premonition” (T. Hinata), an example of setting 
and comprehension; 

(3) “Clair de Lune” (C. Debussy), with right hand only; 

(4) "Dance of the Sugar Plum Fairy,” Nutcracker Suite 
(P. Tchaikovsky), example of sensitivity in the tempo re¬ 
sponse, and; 

(5) Concerto No. 1 for Piano and Orchestra (P. Tchai¬ 
kovsky), with a human pianist, live recording. 

If you would like to order a CD or cassette, refer to 
page 9. 
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MIDI or a computer. In the overall tests 
with this conductor and a number of 
other musicians, we observed some in¬ 
teresting feedback effects on the be¬ 
havior of the users through their audi¬ 
tory sense, which in turn suggested 
some new ways to determine the pa¬ 
rameters of tempo prediction and com¬ 
pensation. 

Moreover, the system can play in con¬ 
cert with human performers and even 
as a part of a symphony orchestra, be¬ 
cause the same human conductor di¬ 
rects both humans and the machine. 
Our system has succeeded in perform- 
l ing, for example, Tchaikovsky’s Con¬ 
certo No. 1 for Piano and Orchestra 
with a human pianist, while following 
the conductor’s delicate gestures. As 
for applications, our system is consid¬ 
ered suitable for providing accompani¬ 
ment for plays, operas, and dance in 
which the music timing often lags due to 
the action. 


T he main means of nonverbal 
communication is gestures. Non¬ 
verbal communication is now be¬ 
ing studied as a new interdisciplinary 
approach in linguistics, cultural anthro¬ 
pology, and psychology. 9 It includes not 
only body language and gesticulation 
but also the grasp of approach (open 
space), involuntary motion, and cus¬ 
toms. 

Musical conducting is a rich area of 
nonverbal communication and provides 
a suitable domain for the study of intel¬ 
ligent human interfaces. In the future, 
we would like to work on a sophisticat¬ 
ed nonverbal interface that can, in real 
time, interpret facial and eye expres¬ 
sions and circumstances, as well as left- 
hand gestures. 

At present, artificial intelligence has 
advanced into the area where engineer¬ 
ing and art overlap. We believe that AI 
should aim to comprehend individual 
senses, emotions, feelings, passions, sen¬ 
timents, intentions, purposes, and cus¬ 
toms from hour to hour to help human 
beings attain satisfaction. 

A computer music system that can 
follow a human conductor is an exam¬ 
ple of a practical, nonverbal interface in 
the human-to-machine communication 
system. Our final goal 1012 is not merely 
to make an instrument but to develop a 
hardware performer that can play with 
human performers in an orchestra. ■ 
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PROJECT OVERVIEWS 



Current Research in 
Computer-Generated 
Music 


The six overviews that follow reflect varied 
ongoing research. Reporting from such diverse locales as 
Singapore, Europe, and the US, the authors explore the spheres 
of computer-aided composition, synthesis of musical scores, 
computer simulation, and composing by musical analog. 


Algorithms for Musical Composition: 
A Question of Granularity 


Stephen W. Smoliar 

Institute of Systems Science, National University of Singapore 
Heng Mui Keng Terrace, Kent Ridge, Singapore 0511 


C omputer programs that “com¬ 
pose” music have been around 
. almost as long as the computers 
that run them. Initial approaches se¬ 
lected notes for a composition using a 
random process with constraints to elim¬ 
inate or modify undesirable choices. The 
computer composition “Illiac Suite for 
String Quartet,” by Lejaren Hiller and 
Leonard Isaacson, demonstrates the 
range of these approaches. 

Experiments with Markov processes 
were probably the most appealing and 


Audio examples 

Examples of the music dis¬ 
cussed in these project overviews 
are available on CD and audiocas¬ 
sette. Please see the order form 
on page 9. 


the most frustrating applications of com¬ 
puter composition in the “Illiac Suite.” 
The appeal lay in the belief that knowl¬ 
edge of past events could serve as a 
valuable predictor for subsequent 
events. The frustration lay in the dis¬ 
covery that there was either too much 
or too little of this knowledge. If the 
number of past events considered was 
too small, the result sounded as random 
as if the notes had simply been selected 
from an arbitrary set of weighted prob¬ 
abilities without any prior knowledge. 
If the number was too large, what was 
“predicted” was nothing more than a 
replication of the original data from 
which the probabilities were computed. 
There seemed to be no middle ground 
between the absolute predictability of 
duplication and the absolute unpredict¬ 
ability of random noise. 

The quest for an appropriate middle 
ground led to an investigation of new 


mathematical models as alternatives to 
Markov processes. The spectral densi¬ 
ties of a wide variety of physical quanti¬ 
ties tend to vary as the inverse of the 
frequency: 1 If. Voss and Clarke demon¬ 
strated such a correlation using the au¬ 
dio signal of Bach’s first Brandenburg 
Concerto and then detected the same 
correlation in signals from classical music 
radio stations. 1 Voss and Clarke con¬ 
ducted similar studies of the music of 
other composers, including Scott Joplin 
and Milton Babbitt. Observing this dis¬ 
tribution in many different sources of 
music, they reasoned that they could 
synthesize new music by a random pro¬ 
cess based on the same distribution. 
Figure 1 shows an example. 

Eric Iverson has explored another 
approach. 2 He applies principles of 
autocatalysis, a chemical process that 
enables the reproduction of molecular 
strings, to the synthesis of “strings” of 
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music — either pitches or intervals. Fig¬ 
ure 2 shows an example of his results. 

The variety in approaches to algo¬ 
rithmic composition is impressive, but 
the results are disappointing. Do these 
results arise from a critical commonali¬ 
ty in these many experiments? I believe 
the commonality is the assumption that 
musical composition requires decisions 
about the placement of notes. 

This assumption is natural enough. It 
has its roots in a pedagogic tradition in 
which the composition student is con¬ 
cerned with manipulating notes on mu¬ 
sic paper. However, music need not be 
notated to be composed. A composer 
can compose while playing an instru¬ 
ment. This is generally known as impro¬ 
visation. Anyone who has heard good 
jazz improvisation can appreciate how 
unlikely it is that musicians who impro¬ 
vise read from some notation they write 
in their head. Thus, if we want a founda¬ 
tion for algorithmic composition, the 
materials provided by the pedagogy of 
musical composition may be far less 
valuable than those of the actual prac¬ 
tice of making music. In this article I 
argue that making music is concerned 
with a higher level of granularity than 
that of the notes on music paper. 

Raising the level of granularity. Mu¬ 
sical composition is not necessarily a 
matter of putting notes together in the 
right way. Long before there was jazz, 
people were making music by working 
with a higher level of granularity. 
Mozart’s Dice Composer, for example, 
generated (to use the terminology of 
computational linguistics) random sen¬ 
tences by selecting productions from a 
simple context-free grammar. Each of 
the terminal symbols in this case was an 
entire measure of keyboard music. Each 
measure of the score, in turn, corre¬ 
sponded to 11 productions, each of which 
filled in that measure with one of those 
terminals. The bulk of Mozart’s work 


with the Dice Composer was to make 
sure that the terminals chosen for any 
given measure were interchangeable. 
Thus, by raising the level of granularity 
to entire measures, Mozart could use 
chance techniques to produce accept¬ 
able music in the classical genre in a 
manner never duplicated by any algo¬ 
rithmic technique concerned with se¬ 
lecting individual notes. 

If raising the level of granularity in¬ 
creases the power of random processes 
applied to musical composition, per¬ 
haps we are thinking about the wrong 
things when we focus our attention on 
the selection of individual notes. Work 
in artificial intelligence shows that such 
low-level decisions may actually be sub¬ 
ordinate to a model-based control struc¬ 
ture. The underlying premise of such 
control is that the knowledge sources 
used to make decisions include actual 
examples of how problems have been 


resolved: These examples are models. 
In musical composition, such models 
include specific compositions or excerpts 
from compositions. David Cope is a good 
example of a working composer who 
has managed to put a model-based ap¬ 
proach into practice. (See Cope’s arti¬ 
cle beginning on page 22 of this issue.) 

An alternative agenda. When we talk 
informally about musical composition, 
we rarely talk about individual notes. 
Composition is a matter of working with 
“musical ideas.” We use this phrase in¬ 
tuitively, without pinning down just what 
it denotes. Nevertheless, following the 
lead of model-based reasoning, we can 
assume that musical ideas include our 
memories of past listening experiences. 
To some extent all composers pick up 
materials from past experiences and find 
new ways to assemble them. 

What do such intuitions tell us about 



Figure 2. Music synthesized by applying principles of autocatalysis to the selection of pitches and intervals. (Reproduced 
with permission. 1 ) 
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algorithmic composition? The primary 
lesson is that our agenda for algorith¬ 
mic composition is off the mark. If we 
are determined to seek out algorithmic 
rules, then our search should be direct¬ 
ed by two questions: 

• How do we identify units of mate¬ 
rial of the appropriate granularity? 

•Given a collection of those units, 
how do we properly assemble them? 

What made Mozart’s Dice Composer a 
clever piece of work was his recognition 
that he could think about simple dances 
(following the style of the dance move¬ 
ments of Bach’s keyboard suites) in 
terms of individual measures. He could 
then ask how any one measure could be 
varied so that it would always “fit” in 
the context of preceding and succeed¬ 
ing measures. He gave these variations 
enough flexibility that any alternative 
for the first measure could be followed 
by any alternative for the second mea¬ 
sure, and so on for the duration of the 
entire composition. 

Perhaps Mozart’s exercise was a par¬ 
ody of the rather routine approach to 
composition he observed in others 
around him. For Mozart, the model be¬ 
came music only after he suitably per¬ 
turbed it, but he could not address ques¬ 
tions of perturbation until he had a model 
in place. The minuet movements that 
Mozart wrote for his more memorable 
orchestral and chamber music could not 
readily conform to this dice model, since 
the model had no good way of imple¬ 
menting material that returns in a simi¬ 
lar, but not identical, form. 

The ordinary versus the extraordi¬ 
nary. The moral of the Dice Composer 
story is that identifying units of appro¬ 
priate granularity and assembling them 
properly is no easy matter. The basis for 
“automating” dice-composed binary 
forms was Mozart’s recognition that it 
was a highly routine activity. However, 
many who pursue algorithmic composi¬ 
tion do so out of “genius envy.” They 
are more interested in the extraordi¬ 
nary than the ordinary, and fail to rec¬ 
ognize that they cannot have the ex¬ 
traordinary without first having the 
ordinary as a point of departure. Any 


music powerful enough to compel us to 
sit still and listen — even one of Bach’s 
two-part inventions or Domenico Scar¬ 
latti’s many sonatas — is probably too 
sophisticated for the analysis required 
in algorithmic composition. Finding 
much past evidence of the ordinary in 
these extraordinary pieces may be diffi¬ 
cult simply because the ordinary rarely 
survives the eroding forces of history. 

However, the ordinary is very much 
with us in the present. We tend to ig¬ 
nore the routine work of composers 
obliged to provide themes and jingles 
for commercial applications. These com¬ 
posers must create on demand, proba¬ 
bly to the extent that none of their tasks 
receive extensive cognitive effort. Here 
is where we may find artisans with a 
clear understanding of the units of ma¬ 
terial with which they work. We should 


look where the ordinary is practiced to 
find a foundation for studies of the ex- 


1. R.F. Voss and J. Clarke, “T//noise’ in 
Music: Music From l//Noise,” J. Acous¬ 
tical Soc. America, Vol. 63, No. 1, Jan. 
1978, pp. 258-263. 

2. E. Iverson and R. Hartley, “Metaboliz¬ 
ing Music,” Proc. Int’l Computer Music 
Conf., Computer Music Assoc., San Fran¬ 
cisco, 1990, pp. 298-301. 


Stephen W. Smoliar is investigating several 
aspects of music cognition and perception in 
addition to his artificial intelligence research 
at the National University of Singapore. 
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Scoresynth: A System for the 
Synthesis of Music Scores Based on 
Petri Nets and a Music Algebra 


Goffredo Haus and Alberto Sametti 

Laboratorio di Informatica Musicale, Dipartimento di Scienze dell’Informazione, 
Universitd degli Studi di Milano, via Moretto da Brescia, 9,1-20133 Milano, Italy 


M usic structures can be de¬ 
scribed, processed, and syn¬ 
thesized using a more flexi¬ 
ble kind of representation than the staff. 
In this article, we show how. In fact, we 
have chosen and organized symbols de¬ 
pending on instrumental needs within 
common music notations. The level of 
representation within scores is more de¬ 
tailed than that of music composition 
and more abstract than that of timbre 
modeling. 

The new kind of representation we 
propose makes up a conceptual music 
framework with as many different lev¬ 
els of abstraction as the musician needs. 
It allows us to explicitly describe and 
process what we call music objects (both 


traditional and nontraditional music 
objects). 

A music object means anything that 
could have a musical meaning and that 
we think as an entity — either simple or 
complex, abstract or detailed — with a 
name and some relationship with other 
music objects. We can describe music 
objects at various abstraction levels with¬ 
in a hierarchical context — for example, 
the structural level, the score level, and 
the timbre level. 

Common music notation is charac¬ 
terized by many different languages (one 
or more languages for each level of rep¬ 
resentation). Our research is devoted to 
the definition of just one language, suit¬ 
able for every level of representation. 
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To identify the most suitable descrip¬ 
tion tool, we sought a formal tool that 

• requires few symbols, 

• has a graphical form of notation, 

• allows hierarchical description, 

• allows the description of music ob¬ 
jects processing, 

• allows time description, 

• allows deterministic/nondetermin- 
istic models, 

•allows macro definitions for com¬ 
mon structures, and 

•shows the musician the score syn¬ 
thesized as the model executes. 



» Name: Theme.mod 

- Net: Voices 
■ Music Object 

- MIDIstring 

- P’ay 

- Start: 91200 sec./2000 

- AT: 76800 sec./2000 


Figure 1. Music object map dialogue with the two windows of Petri net node at¬ 
tributes. 



Score modeling. We have been using 
Petri nets (PNs) 1 as the basic tool for 
music description and processing since 
1980. In our research, we have devel¬ 
oped certain programs to edit and 
execute PNs for both music and gener¬ 
al-purpose applications. 2 The most re¬ 
cent program we developed is called 
Scoresynth. In it, we use PNs to de¬ 
scribe, process, and synthesize music 
scores. 

While we assign music objects (MOs) 
to place nodes for describing music in¬ 
formation, we assign causal relation¬ 
ships and transformation rules to PN 
structures and PN parameters (mark¬ 
ing, numeric labels, algorithms, etc.). 

MOs can be processed by modifying 
the superimposition and juxtaposition 
laws within PN structure. On the other 
hand, PN parameters allow us to create 
instances of MOs that modify them¬ 
selves according to the behavior of PN 
models during execution. Furthermore, 
we can represent the same musical in¬ 
formation by PNs at a lower or higher 
level of abstraction by using suitable 
alternative modeling approaches. 

Indeed, a PN model with a particular 
initial state (that is, initial marking) can 
represent a family of scores; a particular 
execution of the model synthesizes a 
specific score. By modifying the initial 
marking of the model, we can change 
the family of scores that can be pro¬ 
duced by model executions. A special 
situation exists when we have a fully 
deterministic model. In such cases, we 
can produce one only score (given a 
particular initial marking). 

The Scoresynth system is made up of 


the editor and the executer of the mod¬ 
els. 

The editor allows the description of 
hierarchical, timed, concurrent, deter- 
ministic/nondeterministic, and weight¬ 
ed PN models. Both places and transi¬ 
tions are used as the “morphism” nodes 
to implement hierarchy. Common PN 
structures can be described as macros. 
An interactive graphic user interface is 
provided to build PNs by an iconic rep¬ 
resentation. 

The executer performs the models, 
synthesizes MIDI (Musical Instrument 
Digital Interface) scores, and shows a 
graphic map of the MOs as they are 
generated by the model execution (see 
Figure 1). Looking at the map, the mu¬ 
sician can interact with the model, stop 
the execution as soon as a bug is found in 
the model, and proceed to the editor 
environment to make modifications. This 
can be done simply by executing the 
model and looking at a graphic window 
that shows — on a time-MIDI_channel 


plane — the map of MOs as they are 
appended in the score and any informa¬ 
tion requested by the musician about 
the genesis of MOs. 

Music objects. As stated previously, 
the meaning of MOs is strictly related to 
place nodes. To us, an MO encompasses 
not only any sequence of notes but also 
something more general that is not ex¬ 
clusively linked to listening and not con¬ 
nected to the idea of process because it 
could last zero seconds. Obviously, the 
definition of an MO is partly affected by 
the music code standard we use (MIDI) 
and must be kept within the bounds of 
this standard (see Figure 2 as an MO 
example). All MIDI messages, even if 
not directly concerned with a note, can 
be put in an MO. 

MOs can be coded according to three 
syntaxes: 

• a coding language that is specific in 
Scoresynth, 
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(a) 


Theme Alg Theme.mod 


CKHD 

(b) 


Figure 3. A place with an associated 
music object (a); a simple Petri net 
with an algorithm (b). 




Algl: (C: 1, $, [Theme, 1], 1 

{...all on MIDI channel 1; u. 

se “Theme” MO} 

M:l, $, 2} 

{...repeat 2 times} 

Alg2: (C: 1, $, [Theme, 1], 2 

{...all on MIDI channel 2; u. 

se “Theme” MO) 

M:l, $, 2 

{...repeat 2 times} 

P[C]: 1, $, ? + 2} 

(...2 degrees transposition, C major tonality} 

Alg3: [C: 1, $, [Theme, 1], 3 

{...all on MIDI channel 3; u: 

se “Theme” MO) 

D:l,$, 7/2 

{...halve durations} 

M:l,$, 4) 

{...repeat 4 times} 


Alg4: [C: 1, $, [Theme, 1], 4 

{...all on MIDI channel 4; us 

se “Theme” MO) 

1: 1 , $ 

{...retrograde} 

M:l,$, 2) 

{...repeat 2 times} 



Figure 6. The parameter list for invoking the Voices macro Petri net. 


• an alphanumeric MIDI coding lan¬ 
guage, and 

• a coding format that implements the 
Standard MIDI Files 1.0 format (both 
type 0 and type 1). 

The program uses the first format in¬ 
ternally. The second format is based on 
the availability of editing tools (such as 
common word processors). The third 
format has been implemented for file 
import/export. MOs can be defined ei¬ 
ther by a common text editor or by a 
MIDI controller (a keyboard, guitar, 
microphone, etc.). The MOs can be stored 
in separate files (one file for each ob¬ 
ject) or within the PN file to which the 
associated place belongs. 

Figure 3a shows the simplest net to 
perform an MO. We joined the Theme 
place, which has been previously stored 
in a file according to any of the three 
allowed formats, to the Theme MO. 

The upper attribute of the place de¬ 
fines the number of tokens available, 
while the lower attribute specifies the 
maximum capacity of tokens allowed for 
that place. 

The music algebra. The main idea of 
Scoresynth is to make it possible to trans¬ 
form both the parameters of sound (pitch, 
timbre, intensity, and duration) and the 
order in which notes appear, using algo¬ 
rithms. Algorithms join with transitions. 
If a transition has an associated algo¬ 
rithm, Scoresynth merges all the MOs in 
the entrance before making the transi¬ 
tion fire. When the transition fires, it 
takes a token from each input place, 
applies the transformation to the single 
MO obtained, puts the token into all the 
output places, and places the outcoming 
MO into every output place allowed for 
MOs. The transformation can only be 
applied to note events. All the other 
MIDI commands are filtered and lost. 

If Theme stands for the MO on which 
the algorithm is processed at the input, 
the algorithm can be applied to the whole 
Theme or can be limited to one of its 
subsequences, as designated by the mu¬ 
sician. It is also possible to use informa¬ 
tion from every MO available at that 
moment within the whole model. 

An algorithm can be formed by one or 
more single operators. Each operator 
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can affect either the parameters of the 
notes or their order. Each operator is 
applied to the outcoming MO from the 
operator before. Set in its header, the 
algorithm is applied to the range of 
notes as each note occurs. The header 
also defines the kind of parameter to 
which the operator expression must be 
applied—pitch, duration, intensity (key 
velocity), MIDI channel — and the or¬ 
der of the affected notes. Let us exam¬ 
ine two examples of such algorithms. 

(1) Specular inversion. This can be 
done by means of a reference note, called 
the mirror note; that is, every processed 
value of pitch is symmetrical to the mir¬ 
ror note. The following is an operator to 
invert the pitches with respect to C- 
sharp 3: 

P: 1,$, [Theme, 1], 2 * C#3 - ? 
where P stands for pitch; 1, $ stands for 
“from the first to the last note of the 
input MO”; [Theme, 1] determines the 
use of information from the Theme MO 
(not from the MOs joined to the input 
places, which are the defaults and need 
no explicit specification) starting from 
the first note (1); and 2 * C#3 - ? is the 
expression that calculates the new pitch 
values. The ? is a metacharacter that 
represents the value of the parameter 
(in this case, the pitch), assigned to the 
current processed note. 

Other algorithm headers affecting 
note parameters are: 

C (channel) = operator on MIDI 
channels, 

D (duration) = operator on dura¬ 
tion, and 

L (loudness) = operator on inten¬ 
sity (key velocity). 

(2) Inversion of the order (retrogra- 
dation). The inversion operator rewrites 
the input MOs backwards: 1:1, $, where 
I stands for invert, and 1, $ stands for 
“from the first to the last note.” 

Other algorithm headers affecting the 
order of notes are: 

K (kill) = operator for delet¬ 

ing notes, 

S (save) = operator for pre¬ 

serving notes, 

M (multiply) = operator for multi¬ 
plying notes, and 


R (rotate) = operator for rotat¬ 
ing notes. 

Figure 3b shows a very simple net 
that can transform MOs. Here, we can 
join any algorithm we wish to the tran¬ 
sition Alg, decide if we want to enable 
the execution of the Theme and/or 
Theme.mod MOs (setting the specific 
place attributes), and decide if the MO 
obtained from the transformation 
(Theme.mod) should be volatile or 
stored in a file. In this case, a specular 
inversion algorithm may be P: 1, $, 2 * 
C-sharp 3 - ? 

Firing and timing. PNs are particu¬ 
larly suitable for describing concurrent 
processes and controlling their synchro¬ 
nization (or lack thereof). The behavior 
of the net implicitly determines timings. 
We can synchronize MOs simply by suit¬ 
ably structuring the node connections. 
The structure of the net determines the 
firing sequence. 

The firing sequence changes with dif¬ 
ferent executions of the net, so there is 
no correspondence between a net and 
its firing sequence. We can have many 
transitions qualified for firing at the 
same time and not know which one fires 
first. The net does not describe this kind 
of information. Every execution of a PN 
model may give a different firing se¬ 
quence. 

Our approach represents timed MOs 
by places and their transformations by 
transitions. The firing of a transition 
has a null duration. In this way, when a 
token is put into a place with an associ¬ 
ated MO, the token cannot be consid¬ 
ered for the firing of transitions con¬ 
nected to the place until the associated 
MO has ended. 

Hierarchy and macros. In this sec¬ 
tion, we introduce two new concepts: 
hierarchy (refinement) and macro. 

A refinement, called a subnet, is a PN 
that gives a more detailed description 
of a node (either a place or a transition) 
of the upper level of abstraction. If we 
choose to define a subnet associated 
with a place P, then the daughter net 
must have two special places: an input 
place In and an output place Out. Input 
arcs of P become input arcs of In, and 


output arcs of P become output arcs of 
Out. Transitions can be refined in the 
same way. We can also model recursive 
nets (that is, nets that contain them¬ 
selves as refinement nodes). To avoid 
endless recursive expansions, we must 
assign a recursion level number to every 
recursive net. 

Furthermore, when we design a net 
model, we often have to create many 
similar nets that differ in their place 
attributes and algorithms but are iden¬ 
tical in structure. With a macro net, we 
can use just one net as the base model 
and then modify its attributes and/or 
algorithms as needed. This enables the 
musician to create personal libraries 
containing commonly used nets. We can 
do this by writing a modifier list for 
every subnet place or subnet transition 
we want for the net. This modifier list is 
loaded into memory and actualized be¬ 
fore execution of the model. 

Figures 4a, 4b, and 5a represent a 
deterministic model based on the “Are 
You Sleeping” theme, while Figures 4a, 
4b, and 5b represent a nondeterministic 
version of the same melody. (The alter¬ 
native depends on Figures 5a and 5b. 
Figures 4a and 4b are deterministic if 
they are considered stand-alone nets.) 
The IEEE net is the most abstract net. 
The Are You Sleeping place is then 
refined by the homonymous net with 
Input as input place and Voices as out¬ 
put place. The input arc to the Counter 
place has weight 3; this means that the 
firing of the transition will put three 
tokens in the Counter place. The Rest 
4/4 place has a 4/4 rest as an associated 
MO. 

To expand the Voices place with a 
macro net, we can use one of the two 
nets in Figure 5. In the first case, we 
obtain a deterministic execution of the 
model; in the second case, we obtain a 
nondeterministic one. Stated another 
way, we cannot fix the firing sequence, 
but the firing sequence is determined by 
Scoresynth with a pseudorandom uni¬ 
form distribution of the order. 

The Input place has no token as ini¬ 
tial marking because it will receive to¬ 
kens from the upper level of the model 
(in both the Are You Sleeping and Voic¬ 
es nets). Figure 6 shows the parameter 
list for invoking the Voices macro PN 
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(note that we invoke only the actualiza¬ 
tion of algorithms associated with the 
four transitions of the macro net here, 
but we can do the same with respect to 
all the possible attributes of the PN). 

Figure 1 shows the map of the MOs 
obtained from the IEEE model execu¬ 
tion. It contains four different instances 
of the Theme.mod MO belonging to the 
Voices net put on different MIDI chan¬ 
nels. These MOs differ from one anoth¬ 
er because they are generated by differ¬ 
ent algorithms. The other MOs of the 
model are not present in the map (or the 
output score) because Theme was set as 
an MO that is not meant to be played 
and Rest 4/4 produces a delay, since it is 
a rest MO and not a MIDI event. 

Transforming music structures. Our 

research has shown that music struc¬ 
tures can be transformed simply by 

• modifying markings, MIDI channel 
specifications, and capacities of 
places; 

• modifying labels of arcs; 

•modifying MOs associated with 

places; 

•modifying algorithms associated 
with transitions; 

• modifying the structure of PNs; and 


• executing nondeterministicPN mod¬ 
els many times. 

While editing PN structures and pa¬ 
rameters affects causal/structural rela¬ 
tionships within the architecture of 
scores, editing both MOs and algorithms 
affects the basic information units and 
their transformations. We believe that 
the Scoresynth system provides a pow¬ 
erful means for describing and process¬ 
ing music in a way that is closer to music 
thinking and perception than common 
music notation is. ■ 
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Neurswing: An Intelligent Workbench for 
the Investigation of Swing in Jazz* 


Denis L. Baggi 

Via Casagrande 12 

CH-6932 Breganzona, Switzerland 


N eurswing is an intelligent sys- 
j tern to investigate swing in 
j jazz by simulating the opera¬ 
tion of a rhythm section. From an input 
consisting of the harmonic grid of a 
standard tune, it constructs a network 


representing musical data. At runtime 
the system generates and plays the mu¬ 
sic of piano, bass, and drums in real 
time. 

The user can control the performing 
style of the rhythm section by turning 


“knobs,” that is, by setting input 
parameters of a second, separate and 
asynchronous, net, which manip¬ 
ulates the probability of some choices. 

The system can simulate most aspects 
of a performing jazz rhythm section. It 


*This article is an abridged version of previous publications 12 that describe the work performed at the International Computer Science Institution in Berkeley, 
California, whose sponsorship is gratefully acknowledged. 
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(a) 


Figure 1. (a) Structural har¬ 
monic grid of Rhythm Changes, 
the basis of many pieces fa¬ 
vored by jazzmen: “Anthropol¬ 
ogy,” “Dexterity,” and “I Got 
Rhythm.” (b) The harmonic net 
constructed from the grid. From 
top to bottom: measure and 
beat number, piano note units, 
bass note units, drum note 
units, units of the given harmo¬ 
ny (squares), and units of har¬ 
monic substitutions. 



substitutes chords, bass lines, and drum 
licks and has been used by practicing 
improvisers as a didactic tool. Further¬ 
more, the rules for substitution as well as 
the stylistic net are external to the basic 
system and can be configured and altered 
at will, allowing the user to treat the 
system as a workbench for experiments 
in the synthesis and analysis of swing. 

The problem. In jazz the word swing 
has many meanings. It really means a 
holistic, “gestaltic” quality of almost 
extra-musical nature, by virtue of which 
the jazz message is passed to the listen¬ 
er. Swing is the medium for jazz, as 
space is the medium for sculpting. This 
sets jazz apart from classical music, for 
example, where the piece has a quality 
independent of the moment in which it 
is played. In jazz the opposite is true. 


This is why jazz is improvised by defini¬ 
tion. Swing cannot be annotated in a 
music score; rather, it is captured in a 
record, which has been the document in 
jazz since 1917, the accepted date of the 
first jazz record. 

Swing is produced by — though it 
should not be confused with — certain 
technical means such as rhythmic pat¬ 
terns, harmonic progressions, melodic 
accents, and instrument timbres. One 
of its aspects is possibly the opposition 
between an implied regularity of pat¬ 
terns, rhythmic or otherwise, and a con¬ 
sistent yet controlled violation of that 
regularity. This project addresses some 
of these quantifiable, technical aspects 
of swing. 

The system and its possible uses. Neur- 
swing attempts to simulate a jazz rhythm 


section and allows the user to modify its 
parameters at three levels. At the top 
are three stylistic knobs: 

• hot-cool controls the overall impres¬ 
sion of drive and push, as defined 
from the thirties to the fifties, with 
the “hot” elements of swing in op¬ 
position to the “cool” school of the 
early fifties; 

•dissonant-consonant controls the 
overall level of dissonance in the 
underlying harmony; 

•as-is-ness amplifies or reduces the 
level of free substitution versus ad¬ 
herence to the given input — the 
piece — and is thus a control for 
improvisation. 

At the second level, all rules for harmo- 
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Figure 2. The architecture of the system: stylistic net above, harmonic net below. The inputs of the stylistic net produce 
outputs — the hooks — indicated by asterisks and corresponding to those of Figure 3. These outputs affect the probabil¬ 
ity of possible choices in the harmonic net at runtime as well as tempo increase or decrease and delays of piano and bass 
in respect to drums. 
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ny substitution, piano, and drum pat¬ 
terns are in external tables and can be 
modified at will. At the third level, the 
presented stylistic network is just an 
example — an untrained neural net — 
to demonstrate how style can be mod¬ 
eled. It is external to the system, and 
some other network could substitute. In 
this sense, Neurswing is a workbench 
because it allows us to investigate which 
parameters have what influence on 
swing. 

Aside from its scientific interest, Neur¬ 
swing has been used by practicing musi¬ 
cians as a didactic tool, since for most 
purposes it can substitute for existing 
records with jazz rhythm sections (for 
example, Music Minus One and Japa¬ 
nese Karaoke), such records being in¬ 
flexible and of fixed duration, tempo, 
and key. Neurswing, on the other hand, 
is a flexible, programmable system that 
can play any tune in any key and at any 
tempo for as long as desired. It can even 
repeat difficult passages. Neurswing can 
help aspiring musicians control rhyth¬ 
mic accents and correct typical begin¬ 
ner’s errors, such as slowing in difficult 
passages and accelerating in easy ones. 
Control of tempo is an essential tech¬ 
nique in swing; a metronome may offer 
some help, but Neurswing is close to the 
ultimate practicing tool, a real rhythm 
section embodying harmony, rhythm, 
and style. 



Figure 3. The hierarchy of runtime choices expresses the dependency of the 
types of hooks (indicated by an asterisk). For instance, selection of the drum 
pattern constrains the choice of notes played by the drums. 


The input and the harmonic net. The 

harmonic grid (see Figure la on page 
61) is the input to the system. Each 
square of the grid corresponds to a mea¬ 
sure, or four beats, and contains sym¬ 
bols representing chords that determine 
the harmonic structure, though not the 
actual notes. The meaning of these sym¬ 
bols, which are also used in guitar charts, 
is described in the jazz literature. 

This section of the system uses a 
knowledge base to construct a connec- 
tionist model of the jazz performance, 
drawn by the Rochester Connectionist 
Simulator and shown in Figure lb. The 
net units represented by a square con¬ 
tain data of the grid harmony, while the 
units below show the constructed alter¬ 
native harmonies. The symbols above 
the squares represent drum hits, and 
above these are the units of the bass 


notes, initialized from the given har¬ 
mony. The four to seven units just be¬ 
low the measure and beat numbers at 
the top contain the initial notes of the 
piano units. The paths in the section 
representing harmony and the contents 
of the units of piano, bass, and drum 
notes change at runtime under control 
of the stylistic net. The harmonic net 
operates in synchrony with the beat; 
activation passes from all units on a 
beat to those on the next beat and then 
wraps around. 

The net, though only vaguely resem¬ 
bling a neural net or a connectionist 
system (it never converges, and neither 
relaxation nor learning takes place), ex¬ 
ploits the inherent parallelism of such 
models. The paradigm was chosen be¬ 
cause it seems the most convenient way 
to represent the process of jazz impro¬ 
visation, in which one path (harmonic 


or melodic) predominates while many 
others are implicitly activated in the 
background. 

The system architecture. Figure 2 
shows the system architecture. During 
operation of the underlying harmonic 
net, there are several points where it is 
possible to choose among different pos¬ 
sibilities — for instance: 

• kind of harmony substitution; 

•piano rhythmic pattern; 

• type of walking bass — up, down, or 
note from the chord; 

• position of piano chord; 

• drum pattern; and 

• piano or bass appoggiatura. 

All these choices, called hooks, are un¬ 
der control of the stylistic net, shown at 
the top; Figure 3 shows what they are 
and how they relate. 
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The system could operate without the 
stylistic net. This would be equivalent 
to a setting of 0.5 for all three knobs, 
and the system would not exhibit any 
stylistic consistency. Turning a knob 
activates the stylistic net, which in this 
example consists of three inputs, 360 
units in the middle layer, and 360 out¬ 
puts. The outputs, or hooks (indicated 
in Figures 2 and 3 by asterisks), are 
numbers that change the probability of 
a given choice. For instance, an increase 
in the hot/cool knob favors a dense rhyth¬ 
mic piano pattern, more piano appog- 
giaturas, louder playing of the piano, 
walking bass up, more bass appoggiatu- 
ras, more nervous drum patterns, more 
drum fill-ins, and more crash cymbal 
hits. An increase in the dissonance knob 
favors dissonant harmonic patterns, flat¬ 
ted fifth in dominant seventh chord, 
inversion for piano chords, and half steps 
for piano and bass appoggiaturas. 

The advantages of modeling stylistic 
constraints with a neural net are two¬ 
fold. First, complicated interactions 
between related aspects, or parameters, 
can be easily modeled, modified, and 


tested without changing anything in the 
controlled program. Second, hierarchies 
of nets can be conceived to further con¬ 
strain some aspects of style without af¬ 
fecting the operation of underlying nets. 

Performance. Neurswing is a hybrid 
system using a knowledge base to con¬ 
struct a network that contains data for 
jazz improvisation and performance. It 
realizes controllable real-time jazz im¬ 
provisation using neural nets. 

Neurswing performs acceptably for 
tempos between 100 and 250 beats per 
minute (medium to fast) and optimally 
for 180 to 200 beats per minute. The 
time signature is 4/4. Extension to other 
signatures such as 3/4,6/8,5/4, and 6/4 is 
possible, but has not been realized. 

While there are commercial systems 
that simulate a jazz rhythm section, none 
are capable of improvising, that is, of 
elaborating the input with substitutions, 
changes, and drum accompaniment; they 
merely replay what the user typed in. 
Hence, they are not interactive and do 
not allow control during the perfor¬ 
mance, as the knobs in Neurswing do. 


Computer music projects have rarely 
been applied to jazz. Perhaps this work 
will stimulate further investigation into 
the subtle problems of jazz improvisa¬ 
tion and swing. ■ 
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HARP: A System for Intelligent Composer’s Assistance 
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S -: ystems for computer-aided 
composition are generally based 
on tools and languages designed 
for low-level manipulation of music 
scores and composition algorithms. 1 In 
this article, we introduce HARP (Hy¬ 
brid Action Representation and Plan¬ 
ning), a prototype high-level system for 
computer-aided composition. 

We think of the system as providing 
intelligent composer assistance. HARP 
can store and process music and sounds, 
and carry out plans for manipulating 
this material according to composers’ 


goals. The system can generate new 
pieces of music as well as manipulate 
existent ones on the basis of composer- 
supplied material. The system also pro¬ 
vides capabilities for formal analysis of 
both music and sounds, so it can extract 
information useful in subsequent syn¬ 
thesis processes. 

HARP represents and manipulates 
music knowledge using a twofold for¬ 
malism. An object-oriented concurrent 
environment, the analogical subsystem, 
provides procedures to manage the 
sound itself (samples, codes, and algo¬ 


rithms) and particular analysis process¬ 
es. The symbolic subsystem, a declara¬ 
tive symbolic environment, stores high¬ 
er level scores, composition rules, 
definitions in general, and descriptions 
of pieces of music. The symbolic sub¬ 
system is based on a multiple-inherit¬ 
ance semantic network formalism de¬ 
rived from KL-One. 2 There is a formal 
link between the two subsystems. For 
example, if a composer asks the seman¬ 
tic network to generate a particular in¬ 
stance of a music object, the system 
automatically “fires” the appropriate 
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procedures at the analogical level. 

Figure 1 shows part of the HARP 
symbolic knowledge base: Ellipses cor¬ 
respond to concepts in the taxonomy, 
double arrows are “is-a” links, and arcs 
with small boxes correspond to roles 
(slots, relations between pairs of con¬ 
cepts). For example, a music action is-a 
music fact, and one of its roles is inten¬ 
sity, whose value is amplitude. In other 
words, the intensity of a music action is 
an amplitude, as shown in Figure la. 

The HARP knowledge base. We de¬ 
fined two basic music entities in the 
system: the music action and the com¬ 
positional action (see Figure 1). Music 
actions can represent musical material 
at different levels of abstraction, from 
the sonological level (low-level descrip¬ 
tions of sounds) to the whole musical 
form of a piece (for example, fugue or 
sonata). 

Compositional actions are meta¬ 
actions; that is, they are the “manipula¬ 
tors” that operate on music actions (both 
classes and instances) to produce new 
music actions or to perform analysis 
tasks useful for subsequent manipula¬ 
tion. Compositional actions let compos¬ 
ers manipulate music actions according 
to their objectives. For example, a com¬ 
poser can operate on a music action at 
its sonological level for the “tuning” of 
particular sound features. While plan¬ 
ning the overall structure of a part, the 
composer can see the same music action 
as a more abstract, high-level symbolic 
entity and work on its possible relations 
with other music actions. 

The composer can introduce into the 
system subclasses of music actions and 
instances. Subclasses are reusable ob¬ 
jects, skeletons of music scores, or sound 
definitions. Instances correspond to 
complete, individual objects that can be 
heard reproduced by the HARP sound 
output channels. 

HARP’S framework does not refer to 
a particular musical style or context. 
Each context requires the creation of 
suitable definitions in the symbolic part 
and the related analogical procedures. 
For example, in the context of Western 
tonal music, a composer can define the 
subclass canon with its structure: its 
component music actions antecedent and 


consequent, as shown in Figure lb. Suc¬ 
cessively, the composer can introduce 
— or ask the system to generate — a 
particular canon characterized by a giv¬ 
en antecedent and a suitable consequent. 


Basic features of music actions in¬ 
clude 

• a temporal connotation (the begin 
and end roles), allowing the com- 
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poser to relate music actions to each 
other in the time domain, and 
• a set of relations, such as dynamic 
evolution, timbral and density con¬ 
tent, pitch, metrics, and rhythmic 
properties. 

Assume that a composer wants to 
specify in a compositional action that a 
music action (a part Of a piece) N be 
generated in relation to, say, the evolu¬ 
tion of another music action M, ex¬ 
pressed simply as a score fragment. An 
analogical representation of an instance 
of M is formed by a score fragment 
(hooked to the concept M) and by a set 
of functions, or methods, hooked to its 
relations, which extract the related fea¬ 
ture from the score. The composer can 
query the intensity of M, which corre¬ 
sponds to a call to the intensity method 
of M, whose result is a presentation of 
the behavior of the dynamics of M, ex¬ 
tracted from its score fragment. In this 
way, the composer carries out a reason¬ 
ing process, partially in procedural form. 
No a priori assumption has been super¬ 
imposed on the leading features of mu¬ 
sic actions. In classical Western music, 
the melodic aspect could predominate 
in the manipulation of music actions, 
but the system lets the composer mod¬ 
ify or redefine their relations and “ma¬ 
nipulators” according to his or her needs. 

A compositional action is character¬ 
ized by a procedural description of its 
behavior and a temporal connotation 
(with a time axis defined by the mbegin 
and mend temporal roles, different from 
the time axis of music actions). As with 
any other object defined in the system, 
composers can define both subclasses 
and instances of compositional actions. 
Composers can define compound 
compositional actions in the system as 
sets of given compositional actions whose 
execution is ruled by proper constraints 
on their temporal relations. 

System interface. HARP lets com¬ 
posers use different visual interfaces to 
communicate with the system. It pro¬ 
vides a visual presentation of the se¬ 
mantic network formalism. Composers 
interact visually or textually with this 
part of the system by introducing or 
editing elements in the net, and specify¬ 


ing to the system queries whose results 
can be graphically presented. Compos¬ 
ers can make queries on classes and 
subclasses, the definitional part of the 
network, and on instances, that is, indi¬ 
vidual music entities. 

The system shows subsets of the mu¬ 
sical material, allowing different views 
of the same material. In Figure 1, for 
example, the query “show all objects 
from which canon inherits properties” 
results in a display that colors some 
network elements gray to give promi¬ 
nence to a path in the taxonomy. An¬ 
other simple query, “show all about the 
object music action except temporal 
relations,” results in a display of the 
concept music action with all its rela¬ 
tions except the begin and end inherited 
from music fact (see Figure la). 

Reasoning mechanisms. The sym¬ 
bolic subsystem is equivalent to a sub¬ 
set of first-order logic in an artificial 
intelligence system. The system answers 
queries using the symbolic subsystem 
formal deductive apparatus. We have 
implemented a classifier 2 to organize 
concepts in the taxonomy. 

Music actions have “hooks” to score 
fragments, and compositional actions 
have hooks to code “chunks.” This un¬ 
derlying level of procedural definitions 
constitutes the analogical level of HARP, 
which is structured into a sonological 
component and a simulative component. 
The simulative component is formed by 
a set of procedures that acts as a coun¬ 
terpart to the symbolic deductive appa¬ 
ratus and integrates the inference capa¬ 
bilities of the symbolic system. Both the 
simulative and sonological components 
are driven by the symbolic level sub¬ 
system, because proper activations of a 
node in the net correspond to calls to its 
hooked code. 

The system also provides mechanisms 
for visual interaction with the analogi¬ 
cal level of music information represen¬ 
tation. The mechanism is based on mu¬ 
sic notation, sound graphic descriptions, 
and visual metaphors. Here, queries 
correspond to the activation of code 
modules, with the passing of proper 
parameter values. An example is the 
query on the intensity of the music ac¬ 
tion M presented in the previous sec¬ 


tion. Here is another example: A canon 
is generated_by an imitation process 
(Figure lb). A composer can define a 
particular canon subclass, say per dimi- 
nutionem canon, as generated_by a sub¬ 
class of imitation, say per diminutionem 
imitation. The composer can hook more 
detailed procedures to the second con¬ 
cept, and one of them can implement a 
proper diminution algorithm. By que¬ 
rying a proper consequent for this 
canon, the composer can generate an 
instance of per diminutionem canon that 
starts from the above concepts and an 
instance of antecedent. The system an¬ 
swers by activating the proper proce¬ 
dure hooked to per diminutionem imi¬ 
tation, passing as parameters the 
antecedent instance. (We produced ex¬ 
amples 4 and 5 in the available audio 
recording by introducing particular can¬ 
on definitions using suitable subcon¬ 
cepts of canon and imitation. See the 
“Audio Examples” box on page 54 for 
information on how to obtain the re¬ 
cording.) 

Force fields — A recorded example. 

An important set of analogical descrip¬ 
tions in HARP is based on the meta¬ 
phor of force fields. These descriptions 
let the composer think of and perform a 
set of compositional actions in terms of 
the intuitive natural dynamics of navi¬ 
gation in attractor fields, instead of us¬ 
ing a rule base. 

Force fields play a significant role in 
the generation of the examples on the 
available recording. The sixth music 
example is generated starting from a 
phrase (the incipit), a definition of the 
sound parameters, and two concurrent 
force fields operating as follows: The 
initial incipit (easily recognizable as the 
beginning phrase in the example) is 
imitated with continuous timbral varia¬ 
tions. At the same time, the aspect of 
pitch intervals progressively degrades, 
giving place to the timbral aspect. In 
HARP terms, there is a force field oper¬ 
ating on the timbral space, which per¬ 
forms a continuous timbral disassem¬ 
bling according to its field function. 
Concurrently, another force field, op¬ 
erating on the pitch axis, gradually su¬ 
perimposes a variation of the initial in¬ 
cipit. The result is that the application 
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of this force field (which has a function 
with local minima on particular pitches) 
to the incipit causes a gradual pitch 
stretching, which conduces to the final 
melodic contour. 

The metaphor of force fields is useful 
for describing continuous changes in 
music actions. A composer can use sev¬ 
eral force fields to easily model com¬ 
plex behaviors (such as continuous tim- 
bral evolutions), which are very difficult 
to model as rules. Force fields also give 
a different viewpoint on music entities 
and provide powerful manipulation 
primitives. 

With HARP, composers can formu¬ 
late such complex analogical queries, 
involving complex activations of inter¬ 
acting procedures, and build high-level 


music actions. 


eluding the ability to merge different 
knowledge bases while maintaining glo¬ 
bal consistency and detecting conflicts. 
We will implement other knowledge 
bases in the near future. Problems in the 
formalism, such as how to store consis¬ 
tent multiple views of music entities, 
are areas for future research. ■ 


2. R.J. Brachman and J.G. Schmolze, “An 
Overview of the KL-One Knowledge 
Representation System,” Cognitive Sci¬ 
ence, Vol. 9, No. 2,1985, pp. 171-216. 


The other examples. The recording 
includes two groups of musical exam¬ 
ples: a simple improvisation environ¬ 
ment in an Afro-American jazz style, 
and three excerpts from “Anceps Ima¬ 
go,” a contemporary piece for two harp¬ 
sichords and computer-generated mu¬ 
sic (composed by Corrado Canepa in 
1989). 

The first three musical examples are 
simple improvisation fragments. The 
system’s goals were to generate and 
transform suitable musical phrases (the 
soloist improvisation) to follow the com¬ 
poser’s defined harmonic schemas in an 
Afro-American jazz style (blues, bal¬ 
lad, and so on). We stored a set of pre¬ 
defined music phrases in the system in 
terms of assertional constants, or sub¬ 
concepts of music action. Composi¬ 
tional actions take as inputs subsets of 
these phrases for developing improvi¬ 
sations. 

Examples 4 and 5 are two excerpts 
from the first part of “Anceps Imago,” 
in a canon form. Example 6 is described 
above. For the recording, we replaced 
the two harpsichords with computer 
music of a similar timbre. We used 
cmusic as the low-level language to de¬ 
scribe the computer-generated scores. 

The HARP software prototype is 
implemented in Prolog and C, running 
on Apple Macintosh and 386-based 
machines under Microsoft Windows. 

HARP has several other features, in¬ 
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Composition Based on 
Pentatonic Scales: 

A Computer-Aided Approach 
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P entatonic scales—musical scales 
| of five tones — are used in the 
music of many cultures. My 
project uses pentatonic scales to ex¬ 
plore some basic techniques of comput¬ 


er-aided composition. This approach 
can be likened to the study of painting 
using a limited “palette” and may be of 
interest to readers with a background 
in computing and music who want to 
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experiment with computer-aided com¬ 
position. 

Notation (pitch and duration). The 

88 pitches on the piano are usually iden¬ 
tified (from lowest to highest) as AO, 

A#0 (or BbO), BO, Cl.C4 (middle 

C),..., C8. The MIDI (Musical Instru¬ 
ment Digital Interface) standard uses 
integers (0-127) to identify a set of 128 
pitches. The pitches A0-C8 are mapped 
to the MIDI numbers 21-108. While 
many modern MIDI synthesizers have 
alternate tunings, we will assume that 
the default tuning is equal tempered 
based on 440 Hz for A4 (MIDI No. 69) 
so that we will have a fixed frame of 
reference. 

Numeric notation for pitches has def¬ 
inite advantages over the conventional 
names in dealing with computer manip¬ 
ulation of pitch data. The relationship 
between frequency F (in hertz) and 
MIDI note number M is given by the 
formula 

F = 27.5 x S M ~ 2i 

where S is the 12th root of 2 (frequency 
ratio of a semitone or half step) and 27.5 
Hz is the frequency associated with AO. 
In other tuning systems, musicologists 
divide the semitone into 100 equal (in 
terms of frequency ratio) intervals called 
cents, which can be easily incorporated 
into the numeric MIDI notation by add¬ 
ing two decimal places. For example, a 
pitch halfway between C4 (60) and C#4 
(61) is said to be 50 cents above C4 and 
is given a MIDI number of 60.50. The 
equation above still applies for noninte¬ 
gral M. In addition to the computation¬ 
al flexibility it offers, the MIDI note¬ 
numbering system facilitates the 
translation of musical data into stan¬ 
dard MIDI song files for playing with 
MIDI synthesizers. 

We use the number 1 to represent the 
relative duration of a quarter note. The 
exact duration is a function of the tem¬ 
po — for example, the number of quar¬ 
ter notes per minute. Other durations 
follow naturally: 0.5 for an eighth note, 

2 for a half note, and so forth. Rests are 
notated as negative durations; for ex¬ 
ample, -1 for a quarter rest, -1.5 for a 
dotted quarter rest. 


Examples of pentatonic music and 
scales. The examples in Figure 1 are 
excerpts of pentatonic music from many 
cultures of the world. Two pentatonic 
scales are represented in these exam¬ 
ples, namely {C4, D4, E4, G4, A4, C5) 
(variously transposed) and {C4, E4, F4, 
A4, B4, C5}. These are not the only 
pentatonic scales, however. Other ex¬ 
amples of pentatonic scales include {C4, 
D4, E4, G4, Bb4, C5}, {C4, D4, E4, F4, 
A4, C5}, and {60, 62.40, 64.80, 67.20, 
69.6,72}. (At the end of a scale the first 
note is usually repeated an octave high¬ 
er.) The last scale, given in numeric 
MIDI notation, is called the equidistant 
pentatonic, an idealization of a popular 
Indonesian scale known as the slendro. 

Basic composition. The project illus¬ 
trates some basic techniques for mak¬ 
ing music under the guidance of a com¬ 
poser and with assistance from a 
computer, using only a small set of 
pitches for simplicity. A musical com¬ 
position and an English composition 
share some structural similarities. The 
hierarchy of an essay or a book (alpha¬ 
bet, words, sentences, paragraphs, chap¬ 
ters, and volume) is analogous to that of 
a musical composition, which starts with 
an alphabet of pitches and duration val¬ 
ues. These are combined to form 
phrases (motives and themes). Devel¬ 
opment and variation of these basic 
phrases give rise to other phrases. A 
sequence of related phrases forms a 
movement, and one or more movements 
constitute a composition. Additionally, 
an alphabet of chords permits the for¬ 
mation of chord progressions, the har¬ 
monic foundation of a composition. 

Elementary computer-aided compo¬ 
sition techniques 1 include random sieves, 
biased choices, and Markov processes. 
For simplicity, we concentrate on the 
generation of musical phrases with em¬ 
phasis on the two fundamental attributes 
— rhythm and pitch — using an ap¬ 
proach that can be characterized as a 
guided random process based on distri¬ 
butions imposed by the composer. 

Rhythm. A rhythm vector is defined 
as a sequence of real numbers repre¬ 
senting relative note and rest durations. 
For example, the rhythm vector (com¬ 


mas are optional) for the first few bars 
of “Old MacDonald Had A Farm” is 11 
1 1,1 1 2,1 1 11,2-1 1,1 11 1,1 1 2,1 
1 1 1,2-1 .5 .5, 1 1 1 .5 .5, . . . Other 
considerations such as grace notes, n- 
tuplets, staccato, and fermata can be 
handled similarly using the numeric 
approach. 

A rhythm vector can be specified as 
shown above or with the help of a com¬ 
puter program equipped with a pseudo¬ 
random number generator. The com¬ 
poser specifies a biased distribution (or, 
simply, distribution) of duration values 
to reflect his or her preferences for the 
part of the composition being created. 
This distribution is expressed in the form 
of a sequence of ordered pairs (fc„ 75,), i 
= 1, 2,...,«, where k, is a positive 
integer giving the count of the corre¬ 
sponding duration value 75,. The proba¬ 
bility of duration D j being selected is 
equal to its count k i divided by the sum 
of all A:,-, i = 1, 2,. . . , n. For example, 
Rdistl = {(2 .25) (7 .5) (4 1) (2 2) (1 4)} 
specifies a rhythm distribution that can 
be regarded as an “urn” containing two 
16th notes, seven eighth notes, four 
quarter notes, two half notes, and one 
whole note. Items placed in a rhythm 
urn are not limited to duration values of 
single notes. Rests and rhythm phrases 
(short rhythm vectors) are also permit¬ 
ted. For example, Rdist2 = {(41) (2 (.33 
.33 .34)) (2-2) (5 (2 1 1)) (5 (1.5 .5 1.5 
.5)) } is a rhythm distribution in which 
the probability of choosing a triplet (.33 
.33 .34) as a unit is 2 out of 18, or 1/9. A 
function RV assists in generating a 
rhythm vector, given a rhythm distribu¬ 
tion (Rdist) and the total desired dura¬ 
tion (775) of the phrase. 

Pitch. A sequence of pitches repre¬ 
sented in numeric MIDI notation is 
called a pitch vector. Each element of a 
pitch vector can be specified explicitly, 
or a distribution approach can be used 
to generate pitch vectors containing 
composer-imposed biases. Consider a 
given pitch set (a sequence of MIDI 
numbers in increasing order) and a dis¬ 
tribution of skips (defined as relative 
movements within the pitch set). For 
example, Psetl = { 60 62 64 67 69 72 } 
specifies a pitch set corresponding to 
one octave of a pentatonic scale. Pset2 = 
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{55 57 60 62 64 67 69 72 74 76} specifies 
the same scale with a wider range. A 
skip of +1 means move up one note on 
the scale from the current note; 0 means 
repeat the current note; -2 means move 
down two notes on the scale. 

Depending on the current note and 
the skip size, there is a possibility of 
going “out-of-bounds.” One easy way 
to handle an out-of-bounds skip is to 

July 1991 


discard that skip and pick another one. 
Another approach is to transpose the 
resulting out-of-bounds pitch (octave 
up or down) so that it is within the pitch 
range and still satisfies the maximum 
skip limitation that the composer may 
have set. 

A skip distribution is specified as a 
sequence of ordered pairs (k„ S t ), i = 1, 
2 ,,n, where k,. is a positive integer 


count and 5, is a small integer indicating 
a skip. For example, the skip distribu¬ 
tion SKPdist = {(1 -5) (2 -4) (4 -3) (4 - 
2) (6 —1) (4 0)(6 1) (5 2) (8 3) (4 4) (2 5)) 
indicates that the probability of making 
a -2 skip is 4 out of 46, or 2/23; a +5 skip, 
2 out of 46, or 1/23; etc. Function PV 
generates a pitch vector based on a giv¬ 
en pitch set, a skip distribution, starting 
and ending notes for the pitch vector, 
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and the rhythm vector it is to match. 
Although skip sizes are controlled by 
the skip distribution, interval sizes (gen¬ 
erally not the same as skip sizes) can be 
checked and modified as desired. 

Development. A phrase used as a 
theme can be stated, restated, manipu¬ 
lated, and otherwise modified. Com- 

70 


posers constantly create new (some¬ 
times inexplicable) ways to develop 
and manipulate themes. A few possi¬ 
bilities are 

• Reverse the order of elements in a 
pitch vector, a rhythm vector, or both 
(retrograde motion). 

•Invert the intervals or skips of a 


pitch vector (inversion). 

• Transpose the pitch vector. 

• Retain the pitch vector and change 
the rhythm vector, or vice versa. 

•Take portions of the theme and 
develop each portion individually. 

A composition is formed through 
the creative sequencing of phrases ac- 
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cording to some compositional form. A 
computer can be used to experiment 
with ideas that may be too cumber¬ 
some to handle manually. 

A short composition. A short com¬ 
position based on the scale (F3, G3, 
A3, C4, D4, F4) was generated using 
the techniques described in this article. 


Biases in both the rhythm and skip pat¬ 
terns are evident upon examining the 
score (see Figure 2). It may also be 
evident that the parts borrowed rhythm 
and pitch skip patterns from one anoth¬ 
er. I wrote a program to generate and 
manipulate the phrases. The pitch and 
rhythm data thus produced were trans¬ 
lated into a standard MIDI song file 


which was imported into music publish¬ 
ing software (Escort and Score) to pro¬ 
duce the score. The score accurately 
reflects the pitch and rhythm produced 
by the program without additional man¬ 
ual intervention. At this point, the com¬ 
poser can revise parts (or all) of the 
composition. Other elements of the com¬ 
position, such as dynamics and timbres, 
can be added as well. 

Opportunities. The declining cost of 
computers and synthesizers has made 
computer-aided composition accessible 
to anyone with programming skills and 
musical training. While off-the-shelf 
products help the computer musician 
play and print music, to effectively ex¬ 
periment with innovative computer- 
aided compositional techniques, the 
computer musician must be very closely 
involved in translating these techniques 
into algorithms. The possibilities are 
endless, even if we restrict ourselves to 
generating and manipulating musical 
phrases. 

For readers who find this introduc¬ 
tory article and its illustrative techniques 
of interest, I highly recommend the sur¬ 
vey by Loy. 2 It is a good starting point 
for those wishing to learn more about 
computer composition. ■ 
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Composing by Musical Analog: A Look at Planetary Orbits 


Robert Keefe 

School of Music, Ithaca College 
Ithaca, NY 14850 


F t rom the time of Pythagoras, the 
1 term number made audible has 
I come to mean the relationship 
between the pure world of number and 
the sounding world of music. Today, a 
new numerology is generating musical 
compositions using models from proba¬ 
bility statistics, fractal geometry, and 
other nonlinear and chaotic systems. 
This new way of making numbers audi¬ 
ble is now referred to by some compos¬ 
ers as a mapping technique or mapping. 

Mapping pairs the parameters of an 
object or event to the parameters of a 
musical composition, thus creating a 
musical analog. The object or event can 
occur in nature or be man-made and 
will be represented by a series of num¬ 
bers, letters, or symbols. Compositions 
based on such musical analogs are found 
in Heitor Villa-Lobos’ New York Sky¬ 
line Melody (1940) and Montanhas do 
Brasil (1944), which used a scaled-down 
version of the 1940’s New York skyline 
and a mountain range in Brazil, respec¬ 
tively; John Cage’s Atlas eclipticalis 
(1961-62) and Luigi Dallapiccola’s sicut 
umbra... (1970), both of which employed 
star maps and star constellations; Charles 
Dodge’s Earth’s Magnetic Field (1970), 
where numbers representing the earth’s 
magnetic field created the musical ana¬ 
log; and Larry Austin’s Canadian Coast¬ 
lines (1981), where the coastlines of 
Canada were the object. Some compos¬ 
ers have even used the Dow Jones In¬ 
dustrial Average and DNA sequences 
to generate musical analogs. 

My interest in numerical, nonmusical 
structures began in the fall of 1985 after 
I found a set of books called The Ephe- 
merides Tables. These volumes contain 
celestial latitudinal and longitudinal 
coordinates for the sun, the moon, and 
naked-eye planets as seen from the bib¬ 
lical city of Babylon, the site of one of 
the first observatories. The coordinates 
in the tables are generated from a series 


of complex calculations. The formulas 
themselves may be traced back to the 
works of the astronomer Johannes 
Kepler (1571-1630). 

The orderliness and motion of the 
universe has always intrigued me, and I 
felt that this order could be transferred 
to a musical composition. I had been 
writing computer-assisted composition 
programs since 1982 with some very 
satisfying musical results. Hence, I de¬ 
cided to combine my programming skills 
with my interest in the planets and cre¬ 
ate a modern-day music of the spheres. 

My celestial coordinates are made 
audible through an interactive Pascal 
computer program that generates ce¬ 
lestial coordinates for all the planets 
and the earth’s moon as seen from any 
point on earth for any given time frame. 
The program allows me to map these 
coordinates onto the musical parame¬ 
ters of pitch, dynamics, rhythm, and 
duration of a composition in a MIDI 
(Musical Instrument Digital Interface) 
environment, producing a composition 
that is a pure musical analog or choos¬ 
ing only a few musical parameters cre¬ 
ating a composition that is a partial 
musical analog. 

Compositional environment. Three 
factors influenced my use of The Ephe- 
merides Tables in a compositional envi¬ 
ronment: 

(1) Each planetary orbit is unique 
unto itself, similar to itself, 1 and similar 
to other planetary orbits because they 
all adhere to Kepler’s three laws of plan¬ 
etary motion. When a planetary orbit is 
mapped onto selected parameters of a 
composition, common musical elements 
among single orbits, adjacent orbits, and 
nonadjacent orbits might be readily 
heard. These characteristics lend them¬ 
selves quite readily to hierarchical rela¬ 
tionships and also exhibit a 1//distribu¬ 


tion (see Voss and Clarke 2 for an expla¬ 
nation of 1//distribution). 

(2) Since each planet has its own or¬ 
bital speed, any difference between ad¬ 
jacent latitudinal readings will be 
greater with faster moving planets and 
lesser with slower moving planets. This 
characteristic is used to generate the 
durational and rhythmical activity of a 
composition. Conversely, the faster the 
orbit of a planet, the slower the rhyth¬ 
mical activity, and the longer the dura¬ 
tion of a pitch. 

(3) There is a discernible difference 
in latitude among the planets. Mercu¬ 
ry’s swing in latitude for any given year 
might be between -4.91 degrees and 
+3.36 degrees. Saturn’s swing in lati¬ 
tude for the same year might be be¬ 
tween -1.08 degrees and -0.48 degrees. 
Due to these latitudinal variations, each 
planet develops its own melodic profile 
when mapped onto a synthesizer key¬ 
board. Mercury and Venus generate 
disjunct melodies while Mars, Jupiter, 
and Saturn generate conjunct melodies. 
The melodies generated from Uranus, 
Neptune, and Pluto center on only a few 
pitches within a limited range (do, re, 
mi, fa, sol, for example). 

Once the celestial data is generated, I 
map the latitudinal coordinates onto a 
pitch letter name, an accompanying ac¬ 
cidental (a note foreign to a key indi¬ 
cated by a signature), and an octave 
displacement (range on the keyboard). 
The system I devised performs three 
operations on each latitudinal reading. 
For example, if the latitude coordinate 
is 0.25, the following sequence of events 
occurs: 

(1) The rightmost digit “5” from 0.25 
maps onto a pitch letter name from A to 
G. Since our number system is base 10 
and there are seven pitch letter names 
(not including accidentals), some pitch 
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Figure 1. A partial musical analog of “Venus.” 


names must map onto more than one 
digit. This scheme is user-variable and a 
typical mapping might be 

A = 0 or 1 
B = 2 or 3 
C = 4 or 5 
D = 6 
E = 7 
F = 8 
G = 9 

The lOOth’s place of the latitude co¬ 
ordinate also acts as an on/off switch or 
volume control, and a digit may gener¬ 
ate a rest instead of a note. The com¬ 
poser can also introduce more rests if 
desired. Introducing rests allows the gen¬ 
erated musical phrases to be phrases 
instead of streams of notes. Additional¬ 
ly, the longitude of a planet might also 
generate loudness or dynamics. If a plan¬ 
et reaches 360 degrees in longitude, the 
loudness is 100 percent (a dynamic level 
of fff, or fortissimo)-, if the planet is at 
180 degrees longitude, the loudness 
would be 50 percent (a dynamic level of 
mf, or mezzo-forte), and so forth. 

(2) The tenth’s place of the latitude 
number (“2” of 0.25) maps onto an acci¬ 
dental (also composer variable) that is 


immediately linked to the pitch letter 
name. I use only three types of acciden¬ 
tals (sharps, flats, and naturals, leaving 
out double-sharps and double-flats), so 
accidentals and digits must also be dou¬ 
bled up. One mapping scheme may be 

Sharp = 0,1, 2, or 3 

Flat = 4, 5, or 6 

Natural = 7, 8, or 9 

(3) Finally, the entire latitude num¬ 
ber maps onto an octave displacement 
(vis-a-vis a place on the synthesizer key¬ 
board). The wider the swing in latitude, 
the greater the range covered on the 
musical keyboard. If the latitude read¬ 
ings between 0.00 and +1.00 are assigned 
to the range between middle C and C an 
octave higher, the reading 0.25 would 
fall within the third octave. The entire 
mapping process would yield the pitch 
C#3. 

In an earlier algorithm, I reversed the 
roles of the numbers. The tenth’s place 
acted as the pitch generator with very 
unsatisfying musical results. The musi¬ 
cal output centered on only a few pitch¬ 
es within a limited range and with many 
chromatic inflections. However, this 


might prove beneficial to someone us¬ 
ing a microtonally based tuning scheme. 

Durational schemes. As the pitch al¬ 
gorithm is running, a durational algo¬ 
rithm maps latitudinal or longitudinal 
coordinates onto composer-defined du¬ 
rations. The composer has three types 
of durational schemes from which to 
choose: 

(1) Taking the absolute value of ad¬ 
jacent latitudes or longitudes as deter¬ 
mined by the formula abs(lat2-latl) or 
abs(lat2/latl) and using that as a dura¬ 
tional value in seconds or fractions of a 
second. 

(2) Using a coordinate that falls be¬ 
tween a specified range and mapping 
the value onto a designated rhythmic 
value. For example, latitudes that fall 
between +1.00 degrees and +1.99 de¬ 
grees may be assigned to a quarter-note 
rhythmic value. Latitudes between +2.00 
and +2.99 may be given a half-note val¬ 
ue, and so forth. 

(3) Superimposing a constant rhyth¬ 
mic value over all pitches such as all 
16th-notes, all eighth-notes, or other 
rhythmical values. 

Figure 1 shows “Venus” (from my 
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Figure 2. An excerpt from the Three Movements for Imaginary Dancer, movement I: “De Stella Nova,” a polyphonic 
version of the planetary analog. 


composition The Earth is the Circle Which 
is the Measure of All (1988)) as a partial 
musical analog because it only uses the 
pitch and volume portion of the algo¬ 
rithm. (Figure 1 shows only the first 10 
seconds of the work.) A constant dura¬ 
tional value of 16th-notes is superim¬ 
posed over all computer-generated pitch¬ 
es. The upper part of Figure 1 shows the 
latitude of Venus’ orbit from July 19, 
1595, to October 1, 1596, as seen from 
Graz, Austria. The lower part of Figure 
1 displays the musical analog of the plan¬ 
etary orbit. “Venus” can be heard in its 
entirety on the cassette tape and com¬ 


pact disk available in conjunction with 
this issue (see the order blank on p. 9). 

Figure 2, an excerpt from my compo¬ 
sition Three Movements for Imaginary 
Dancer, movement I: “De Stella Nova” 
(1991), is a polyphonic version of the 
planetary analog. In this excerpt, all 
eight planets (as well as the earth’s moon) 
are made audible as they are panned 
across the stereo listening field from 
left to right. Mercury to Pluto, resulting 
in a modern-day music of the spheres 
composition. Figure 2 is an example of 
a pure musical analog, where all musi¬ 
cal parameters are generated by the 


planetary data. (The tape and CD con¬ 
tain an excerpt from Three Movements 
for Imaginary Dancer.) 

Decisions on options. Creating a mu¬ 
sical analog from planetary orbits re¬ 
quires a sensible understanding of the 
simple physical properties of our solar 
system and incorporating them into the 
compositional process. The more I know 
about the celestial model, the better 
equipped I am in making a musical an¬ 
alog that reflects the structure of the 
model. I then have the option of decid¬ 
ing whether to make a pure musical 
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analog where all of the musical param¬ 
eters are generated by the computer 
program (as in “De Stella Nova”) or a 
partial musical analog where I take ar¬ 
tistic control over the computer music 
output (as in “Venus”). 

This is by far the most difficult deci¬ 
sion to make when dealing with com¬ 
puter-generated or computer-assisted 
music and one that I face each time I 
compose. I cannot codify my intuitive 
process in a few paragraphs, but I can 
say that my compositional creativity is 
influenced by all the different types of 
music I have listened to and/or per¬ 
formed over my lifetime. 

The fine line between adjustment and 
acceptance of computer output is con¬ 
stantly being redrawn with each new 
composition. However, my intuitive pro¬ 
cess seems to maintain a series of sub¬ 
conscious checks and balances over each 
composition, whether it be a computer¬ 
generated tape piece or a work for acous¬ 
tical instruments. 3 Nonetheless, even my 
intuitive process may be altered with a 
new stimulus or input. One of the more 
fascinating aspects of computer- 
assisted composition is that sometimes 
the computer gives you unexpectedly 
pleasant musical results that might not 
have been otherwise realized. ■ 
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STANDARDS 


Standard Music Description Language complies with hypermedia standard 

Steven R. Newcomb, TechnoTeacher, Inc. and Florida State University 


The Standard Music Description 
Language is an application of the Hy- 
Time Hypermedia/Time-based docu¬ 
ment structuring facilities. Using Hy- 
Time and adding tools specific to the 
representation of music, SMDL pro¬ 
vides a comprehensive machine- and 
human-readable means for expressing 
music information for interchange- 
ability. 

SMDL is needed 

• by the publishing industry so that 
music information can be represented 
in any other kind of unformatted doc¬ 
ument as abstractly as text, and so 
that a single formatting application 
can seamlessly govern the rendition of 
the entire document, without paste¬ 
ups (or their electronic equivalents); 

• to provide interoperability to in¬ 
teractive computer-based documents 
(such as business presentations) that 
contain music so that the music can be 


rearranged for various performing re¬ 
sources and situations by an intelli¬ 
gent system (or skilled person) at the 
last possible moment; and 

• to justify and allow creation of 
comprehensive databases of music, to 
allow “on-site and on-demand” print¬ 
ing of music for sale, and to support 
computer-assisted music instruction 
activities. 

In addition (perhaps this so obvious 
it doesn’t need mentioning) composers, 
performers, and arrangers would be 
better able to exploit the market for 
their creativity, and the market would 
be better served and have a wider vari¬ 
ety of products to choose from if we 
had a lingua franca for music. This sin¬ 
gle representation would be able to en¬ 
compass the kind of information avail¬ 
able from printed music, as well as the 
gestures, nuances, etc., musicians 
weave into any given performance. 


Domains of information. SMDL as¬ 
sociates four domains of information 
with any piece of music: 

• the visual domain is the scoring in¬ 
formation; 

• the gestural domain is the perfor¬ 
mance information; 

• the analytical domain is the theo¬ 
retical information; and 

• the logical domain (called the can- 
tus) is the underlying musical in¬ 
formation, which abstractly repre¬ 
sents compositional intent. 

Visual and gestural domains. A sin¬ 
gle SMDL document might encom¬ 
pass an arbitrary number of perfor¬ 
mances and an arbitrary number of 
scores, all referring to a single cantus. 
The visual domain of a given docu¬ 
ment might comprise any number of 
printable editions of the music (or it 
might be empty), and the gestural do¬ 
main might comprise any number of 
performances (see Figure 1). 

Each event (glyph?) in each in¬ 
stance (edition) of the visual domain, 
and each event (pluck? stroke?) in 
each instance (performance) of the 
gestural domain can carry a pointer to 
the corresponding abstract event in 
the cantus. In this way, all correspon¬ 
dences between the visual and gestur¬ 
al domains can be made explicit. 

The gestural and visual domains can 
contain spurious events (events with 
no corresponding cantus events) and 
lacunae (failures to render cantus 
events). In addition to such errata, 
both domains can indicate such things 
as page layout, marginalia, editorial 
remarks, extramusical sounds, and 
stage directions. 

Analytical domain. The analytical 
domain is a playground for music the¬ 
orists. Its use will facilitate theoretical 
and musicological discussions of musi¬ 
cal structure, thematic transformation, 
performance and engraving practices, 
and analytic techniques. 

Logical domain (cantus). The can¬ 
tus contains all the information about 



Figure 1. Domains of description in the Standard Music Description Language. 
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the work considered “essential” and 
common to all domains. The cantus 
information set includes the minimum 
information necessary for an automa¬ 
ton to generate both a minimally ac¬ 
ceptable printed score and a mini¬ 
mally acceptable synthetic perfor¬ 
mance. The music information in the 
cantus is in sufficiently abstract form 
that — theoretically at least — any 
two canti can be compared more or 
less directly to determine whether 
they are essentially the same work. 

A useful (and overly simple) work¬ 
ing definition of cantus is “pitches and 
durations (that is, timing).” Most can¬ 
tus events are musical notes that have 
both pitch and duration. Pitches and 
durations are necessarily represented 
outside the cantus (that is, in the visu¬ 
al or gestural domains) only when the 
given formatted instance of the music 
(an edition or performance) must rep¬ 
resent performed or printed events 
that have no corresponding event in 
the cantus. 

It has been proposed that SMDL 
not provide any facilities for repre¬ 
senting editions or performances at 
all, since a welter of such standards al¬ 
ready exist. Furthermore, the pro¬ 
posal calls for SMDL to merely pro¬ 
vide a standard way to represent “lo¬ 
cations” within files in established 
digital music notations, such as Darms 
(Stefan Bauer-Mengelberg, Raymond 
Erickson, and Bruce McLean), Mus- 
tran (Jerome Wenker and Donald 
Byrd), Score (Leland Smith), Finale 
(Phil Farrand), and MIDI (Musical 
Instrument Digital Interface) Files 1.0 
(Dave Oppenheim), and even nota¬ 
tions not specifically music oriented, 
such as Postscript or CGM. 

HyTime’s document location ad¬ 
dressing facilities are ideally suited to 
identifying specific subsets of data in 
such documents and can be used in 
concert with HyTime hyperlinks to 
make all useful relationships between 
performances and editions explicit. 
Such an address might be expressed as 
some number of quanta starting at 
some quantum number, where quanta 
are bytes, tokens, or tree nodes, or it 
might be expressed semantically in 
some user-specifiable query language, 
for example, “the fourth sonority from 
the beginning of the recapitulation.” 

Timing of cantus events. Like many 
computer-oriented music representa¬ 
tions, SMDL regards music as a com¬ 
bination of sequences (groups) of 
events. Notes and rests or words or 
syllables of lyrics constitute the events 
or event groups. The events occur in 
“thread” and “lyric” schedules in a fi¬ 


nite coordinate space of one dimen¬ 
sion (time). Each event has a position 
(start) and extent (duration) on the 
one coordinate axis of the schedule 
(see Figure 2). 

Both position and extent may be 
specified by explicit addresses on the 
axis and/or by reference to the start or 
duration of some other event. Specifi¬ 
cation by reference to some absolute 
time (for example, Universal Time 
Coordinate) is also possible. 

The ability to define events in terms 
of each other provides an economy of 
notation especially evident in cases 
where schedules or portions of sched¬ 
ules can be represented (for repeti¬ 
tion, for example) merely by refer¬ 
ence. Defining events relatively also 
means that proportionality can be 
maintained regardless of variations in 
the rate at which scheduled time is 
rendered. 

In music, the same time units are 
not necessarily of equal real-time du¬ 
ration. The rate time goes by (the du¬ 
ration of each “beat”) can be variable, 
although the duration of events is still 
rigidly measured as some rational 
number of beats. In SMDL, the rate 
beats go by is controlled by a HyTime 
construct called a baton (a metaphor 
for the stick the orchestra conductor 
uses). 

Batons are special schedules in the 
cantus whose events may be thought 
of as tempo directives. Each tempo di¬ 


rective has a start time and duration 
specified in the baton that associates 
it with those events scheduled in the 
cantus for which it will establish the 
tempo (the beat rate). 

To represent musical meter, SMDL 
provides a “stress template” facility. In 
music, meter establishes what amounts 
to a repeated pattern of dynamic and/ 
or agogic accents that is imposed on 
the beats of every measure (a waltz, for 
example, is written “in three,” and 
each measure is usually played accord¬ 
ing to the stress pattern commonly ex¬ 
pressed as “OOM-pah-pah”). 

Pitch in cantus events. SMDL’s 
pitch representation mechanism was 
designed with the needs of every 
school of thought about musical pitch 
in mind. 

In SMDL, pitch (that is, frequency) 
representation might be by lookup ta¬ 
ble {gamut), by a ratio of the frequency 
of some other pitch (“just” intonation), 
or by user-defined function. Whichever 
approach is used, the resulting pitches 
are “nominal” and subject to detuning 
and variation (for example, vibrato) by 
additional optional facilities. 

Gamut-based pitches. The word 
“gamut” is used generically in SMDL 
parlance to mean any lookup table of 
named items. It is also used in the tra¬ 
ditional sense of “musical scale,” that 
is, a resource table of named pitches 



Figure 2. Structure of the logical domain (cantus) of a Standard Music Descrip¬ 
tion Language document. 
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used to refer to their respective fre¬ 
quencies. 

Convenient shorthand notation is 
provided for 12-tone equal tempera¬ 
ment; it will probably be used in the 
bulk of the music that SMDL will be 
used to represent. Several of the ideas 
inherent in the traditional 12-tone 
equal temperament gamut are gener¬ 
alized in the SMDL pitch representa¬ 
tion mechanism to provide flexibility 
and convenience for those who want a 
more variegated harmonic language. 
These ideas include 

• pitch name equivalence and pitch 
pattern repetition at some arbitrary 
octave frequency ratio, 

• equal division of the octave ratio 
into an arbitrary number n of pitches, 
where each pitch is proportional to 
the base frequency as the nth root of 
the octave ratio, and 

• the ability to distinguish between 
“diatonic” (that is, named pitches — 
for example, C, D, E) and “chromat¬ 
ic” pitches (in SMDL, the singular 
and plural are “fictum” or “ficta,” re¬ 
spectively) which borrow their names 
from adjacent diatonic pitches (for ex¬ 
ample, C-sharp, E-flat). 

Decomposing the pitch system rep¬ 
resented by ordinary 12-tone equal 
temperament into its underlying as¬ 
sumptions (that the octave ratio is 
two, that there are 12 pitches in an oc¬ 
tave, and that seven of those pitches 
are diatonic), and making those as¬ 
sumptions modifiable creates a pow¬ 
erful set of alternative pitch-system 
modeling capabilities. 

If equal temperament is not desired, 
another way of declaring a gamut- 
based pitch system is to express its ref¬ 
erence octave as a set of arbitrary ab¬ 
solute frequencies. If the concept of 
octave equivalence is not applicable 
to the pitch system, the reference oc¬ 
tave can be extended to include all the 
available pitches. 

All of SMDL’s variant gamut-based 
pitch mechanisms support the SMDL 
interval representation mechanism 
and its two chord representation 
mechanisms. 

Just-intoned pitches. At its highest 
conformance level, SMDL allows the 
frequency of any musical pitch to be 
expressed as proportional to the fre¬ 
quency of any other pitch. The rela¬ 
tion is expressed as the ratio of two 
integers. The frequency of a note thus 
expressed can be made to depend on 
the frequency of every other note in 
the piece, implying that the frequency 
of the tonal center of a piece of tonal 
music may wander a bit. 


For the first time in history, we can 
build instruments that can help people 
perform such works; because of the 
complexity involved, this was not 
practical before computer-based musi¬ 
cal instruments came on the scene. 

The SMDL module that supports just 
intonation is optional, although judi¬ 
cious use of just-intoned sonorities 
provides a wealth of harmonies and 
colors that are simply unavailable 
from the 12-tone equal temperament 
palette. 

User-defined functions for pitch, 
etc. Entire sound objects (not just 
their pitches) can be described by 
user-defined functions in arbitrary no¬ 
tations. In SMDL, such an object is 
called a computer-created rendition of 
music activity. The CCRMA object 
was designed to deal with the prob¬ 
lems of representing aleatory music 
(music of chance), stochastic composi¬ 
tional algorithms, and a wide variety 
of other models of musical and com¬ 
positional processes. 

Standardizing the representation of 
such pieces is beyond the scope of 
SMDL but, by minimally conforming 
to SMDL, the non-SMDL notation(s) 
in which the music is expressed — in¬ 
cluding explicit references to the par¬ 
ticular hardware and/or software sys¬ 
tems required to render them — can 
be expressed in a manner that can be 
recognized, even if not decoded by 
any system. 

Chords and chord symbols. A con¬ 
siderable effort has been made to fa¬ 
cilitate the representation of abstract 
harmonies. There are two well-estab¬ 
lished traditions in chord notation: 
figured bass and commercial chord 
symbols (CCSs). Donald Sloan did 
most of the work on the figured bass 
representation, and Ron Gorow was 
the point man on the CCS work. 

The two notational conventions 
come from wildly different musical 
styles and are fundamentally incom¬ 
patible with each other; no single 
chord representation scheme can con¬ 
veniently handle the demands of both. 
SMDL provides separate, compact 
representations for each system and, 
in the case of CCSs, allows a resource 
table of named chord descriptions to 
be declared for convenience. 

Instrumental and vocal sounds. An 

SMDL document can say that a given 
schedule is to be played by an English 
horn, but it provides no standard syn¬ 
tax for describing the sound of an En¬ 
glish horn. The committee took the 
position that timbral information is 


normally not musically essential in the 
same sense that other cantus informa¬ 
tion is essential. 

On the other hand, if timbral infor¬ 
mation is ever considered essential 
enough to provide in the context of 
the cantus, a specific finite coordinate 
space could be constructed for each 
musical note event to describe the 
timbre of each note as a complete 
composition, perhaps realizable — for 
example — by additive synthesis. 

The variety of musical performing 
directions used to modify the charac¬ 
ter of music events defies decomposi¬ 
tion and categorization. An instruc¬ 
tion to depress the piano’s damper 
pedal, for example, not only affects 
the perceived durations of the notes it 
governs and changes the character of 
the instrument’s percussive mechani¬ 
cal noises, but it also adds the sounds 
made by the sympathetic vibrations of 
all the undamped strings in the instru¬ 
ment, even if they are not struck. 

Some performing directions affect 
only the timbre of sustained tones, 
while others affect articulation; still 
others change only the sound of the 
start of each note. 

In SMDL, modifying, filtering, and 
other processing instructions are spec¬ 
ified in a schedule called a wand. A 
wand is a HyTime construct similar to 
a baton; in a wand, however, all modi¬ 
fier semantics are user defined, and 
only the means of expressing the ex¬ 
tent of each modifier’s effect is de¬ 
fined by the standard. Like the signal¬ 
processing modules used in music 
synthesizers, modifiers can be daisy- 
chained and built into patches. 

Nonwestern music. Although the 
scope of the SMDL project does not 
include music not normally represent¬ 
able in ordinary western music nota¬ 
tion, I am led to believe it can repre¬ 
sent most — if not all — nonwestern 
music. 

Since the appearance of an SMDL 
document is entirely a matter of for¬ 
matting, it should be possible to for¬ 
mat a Mozart score as Indian music, 
and Indian music as common western 
music notation. (Indeed, the Music 
Notation Modernization Association 
has expressed interest in creating 
SMDL-compliant formatters for their 
proposed replacements for traditional 
western music notation.) 

In the case of performed music, 
SMDL’s timing and pitch mechanisms 
offer so much flexibility that it is diffi¬ 
cult to imagine how a nonwestern per¬ 
formance tradition could fall outside 
its representational ability. The 
SMDL committee would welcome ed- 
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ucated assessments of the applicability of SMDL to, for ex¬ 
ample, Balinese gamelan music. 

SGML provides the basis. HyTime and SMDL are based 
on the Standard Generalized Markup Language (ISO 
8879-1986), a language for expressing the syntax of docu¬ 
ment types in an application-independent fashion. SGML 
allows the interchange of documents between dissimilar 
authoring, formatting, storage, and retrieval systems in 
such a way that the structure and accessibility of the docu¬ 
ments are preserved. 

In addition to being a standard metalanguage for the 
formal expression of the syntactic design of document rep¬ 
resentation languages, SGML is an international standard 
for document representation. It has been adopted by sev¬ 
eral of the world’s largest publishing houses, including the 
US Department of Defense and the Parliament of the Eu¬ 
ropean Community. Many of the world’s largest software 
and hardware companies support it or plan to. 

One of the goals of the American National Standards In¬ 
stitute’s X3V1.8M project has been to increase opportuni¬ 
ties for musicians in the Information Age. It is important 
that music information be allowed to enter the mainstream 
of information processing. 

For more information 

IBM’s Charles F. Goldfarb, who serves as chair of the 
ANSI’S X3V1.8M project and as project leader of the In¬ 
ternational Organization for Standardization’s CD 10744 
and 10743 efforts, will discuss the HyTime standard in this 
department next month. HyTime and SMDL are currently 
being internationally balloted as Committee Drafts ISO/ 
IEC CD 10744, and ISO/IEC CD 10743, respectively. The 
balloting will close July 31. 

For additional information on 

• the SMDL, circle 173 on the Reader Service Card. 

• tutorials and the Computer Music Association’s Inter¬ 
national Computer Music Conference (ICMC) in Montreal 
October 16-20, circle RS No. 174. 

• conferences where relevant presentations and discus¬ 
sions are to be held, circle RS No. 175. 

• the SGML Users’ Group Special Interest Group on 
Hypertext and Multimedia (SIGhyper), circle RS No. 176. 


Clarification offered over magnetic 
fields from electric blankets 

Fletcher J. Buckley 

An article in the April 1990 issue of Computer (pp. 95- 
97) noted that evidence of cancerous effects of low-level 
magnetic fields had been accumulating. A January 1991 
follow-up article (p. 98) noted that using rectifiers with 
electric blankets (to change AC to DC) can eliminate the 
magnetic fields in the frequencies of interest. 

This has been the source of some confusion and further 
correspondence. For clarification, the frequencies of interest 
(to me) are from about 15 to 70 hertz. Others have taken is¬ 
sue with this (previously unexpressed) range. Further, the 
need to use a power supply choke (inductor) to reduce the 
harmonics that start at 120 Hz was not previously stated. 

None of this should be considered a cure-all. The safest 
course of action, as expressed by another, is to buy a 
down-filled comforter, pull the plug on the electric blan¬ 
ket, and, if it gets very cold, whistle up the dogs. 
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ACADEMIC 
POSITIONS IN 
COMPUTER SCIENCE 

The following positions are available immediately 
within the Discipline of Computer Science which 
comprises 18 staff positions, offers a major, an honours 
programme and postgraduate opportunities. The 
Discipline is expanding its teaching and research 
activities in Information Science and Technology and 
establishing cooperative education and collaborative 
research programmes. Extensive computing facilities 
include a range of Sun-compatible servers along with 
various workstations and PCs. Staff research interests 
cover a wide range. Research opportunities are 
available through the recently established 
CSIRO/Flinders Joint Research Centre in Information 
Technology, the Director of which is Professor Mudge, 
Foundation Professor of Computer Science. A new 
building, to be completed late 1991, will house both 
the Discipline and the Joint Research Centre. In due 
course, it is intended to install advanced 
communication technologies to support teaching 
initiatives such as a tele-classroom and to provide a 
leading edge experimental research facility. 

A higher degree or its equivalent, together with 
suitable professional experience, essential for all three 
positions. Applications from all research areas in 
Computer Science encouraged. 

Reader/Associate Professor 
(Tenurable): $A57 493 pa 

Ref No 912581. One position is available at this 
senior level, to complement two Chairs in Computer 
Science, the second of which is presently being 
advertised. Demonstrable achievements in teaching 
and in research and development projects, preferably 
in conjunction with industry, essential. The appointee 
will be expected to contribute significantly to the 
Discipline’s management and to the success of its new 
teaching and research initiatives. 

Lecturers x 2: $A33 163 - $A43 096 pa 

Two appointments, one tenurable (Ref No 912591) 
and one limited-term (three to five years in the first 
instance) (Ref No 912601) are available. Duties 
include teaching and supervision in the Discpline’s 
graduate and undergraduate programmes as well as 
administrative and other duties as directed. 
Appointment will not normally be made above the 
sixth level of the scale, viz $A40 257 pa. 

Further enquiries to Head of Computer Science 
Discipline, by email to cpos@cs.flinders.oz.au, or by 
fax on 61-8-2012904. Opportunities exist for 
supplements via consulting, external courses and a 
negotiable retention allowance. 

Applications, quoting the reference number, and 
giving full details of qualifications and experience and 
the names and addresses of three referees of whom 
confidential enquiries may be made, should be lodged, 
in duplicate, with the Manager, Human Resources, 

The Flinders University of South Australia, 

GPO Box 2100, Adelaide SA 5001, Australia 
by 16 August 1991. 
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PRODUCT REVIEWS 


Editor: Richard Eckhouse, University of Massachusetts-Boston. 
Send review submissions to MOCO Inc., 776A Country Way, N. Scituate, MA 02066; Compmail; r. eckhouse; Bitnet, eckhouse@cs.umbsky. 


Pascal and Modula on parade 

This month we review products that use the Pascal and 
Modula programming languages. We also present other prod¬ 
ucts worth looking at and several interesting review notes. As 
usual, a number of reviewers contributed to this column. 


Dr. Pascal for VAX/VMS 

John A. Lutts, University of Massachusetts-Boston 


Visible Software describes its Dr. 
Pascal 2.0 as “an integrated program 
development system with editor, for¬ 
matter, Pascal interpreter, and visible 
program execution.” It claims the 
package helps beginners, teachers, 
and professional programmers. I was 
primarily interested in how useful this 
software and the user manual would 
be to my students and me in an intro¬ 
ductory Pascal programming course. 

I tested Dr. Pascal on a VAX 7800 
running VMS Version 5.3, using a 
Zenith 29 terminal (simulating a 
VT100) at 9,600 or 1,200 baud (the 
latter through a telephone modem). 
Because the software ran on a ma¬ 
chine for which the VAX-11 Pascal 
compiler was not available, direct 
comparisons were not possible. Most 
claims made in the user manual were 
tested in this environment. 

Command sheet. Accompanying the 
manual is a sheet providing two sum¬ 
maries of Dr. Pascal command keys: 
one with the commands placed in the 
DEC VT100 keypad diagram, the oth¬ 
er with them listed alphabetically. 
Aside from a reversal of the “more 
delay” and “less delay” labels in the 
keypad diagram, the sheet is very ac¬ 
curate. It is a necessity for beginners 
because not all commands immediate¬ 
ly needed by the user display at the 
top of the screen, despite the manual’s 


claim to the contrary. The help com¬ 
mand displays at the top of the screen 
at all levels of operation, supplying 
useful information about commands. 

Tutorial. After brief introductions 
to the setup in the first two chapters, 
the user manual acquaints beginners 
with facets of the software through a 
tutorial sequence. By and large, this 
tutorial succeeds quite well. 

The discussion explains how the 
software makes program code visible 
on the screen while it is being execut¬ 
ed (each statement is put into reverse 
video at the time of execution). You 
can adjust the execution rate to avoid 
blinding speeds. You can even freeze 
the execution and step through pro¬ 
gram statements one at a time. More¬ 
over, the current value of each rele¬ 
vant variable displays in its own 
labeled box during this execution. 
Such features are invaluable to the in¬ 
structor doing demonstration pro¬ 
grams and for students having trouble 
understanding just what happens in 
program execution. 

Also discussed are methods for 
finding and correcting runtime, logi¬ 
cal, and compiler errors. Visible mode 
helps the beginning programmer find 
the first two types of errors and use 
the built-in editor to fix a program 
bug. Since the editor and compiler are 
intimately linked, compile-time errors 


are highlighted in reverse video when 
the edit key is pressed. Executing the 
explain-compiler-error command 
yields a diagnostic message about the 
error. The editing keys let the pro¬ 
grammer correct the code containing 
the error. Once any error in that part 
is fixed, you can immediately attempt 
a recompile and/or run. 

If more errors occur after the 
change(s), you can easily repeat the 
diagnose/fix/compile cycle. You can 
also easily save the update of the orig¬ 
inal code and either continue to shape 
the program or leave it with the 
changes saved. 

This tutorial also introduces Pascal 
keys: simple control sequences that 
place various program structures into 
the editing buffer in formatted form. 
The mnemonics for the various keys 
are reasonable and convenient for 
those who are not good typists. How¬ 
ever, the command set should be ex¬ 
panded to include the kind that delete 
a structural pattern from the text. The 
current commands also do no error 
checking; their role is solely to facili¬ 
tate the entry of programming parts 
by shortening necessary input. 

Next discussed are subprograms, 
specifically using the editor to put 
them in the program and watching 
their execution in visible mode, etc. 
(Actually the manual and the software 
heavily favor using the term “proce- 
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dure” rather than the more generic 
“subprogram.” A beginner might 
wonder if functions are recognized at 
all. This is an unfortunate bias.) 

The software presents a marvelous 
opportunity for students to see the be¬ 
havior of call-by-reference and call- 
by-value parameters. Its setup also 
strongly emphasizes modular pro¬ 
gramming. The package 

• allows editing in only one module 
at a time, 

• diagrams the subprogram depen¬ 
dency structure of the subprogram 
as it is declared, 

• gives a running record of the se¬ 
quence of calls of subprograms 
and their logical dependencies, 
and 

• separately windows the execution 
of each subprogram. 

The software also lets you edit the 
file containing the program as a non¬ 
program, so that you can transcend 
subprogram boundaries in the editing 
phase. This is especially needed when 
subprogram boundaries have been 
messed up by lack of the appropriate 
pairs of begin ... end’s. The method 
of handling messed-up procedure 
boundaries, however, could be made 
much simpler. 

The tutorial provides some advance 
techniques for making several subpro¬ 
grams visible at the same time. The di¬ 
rectives are clear and work well. They 
are also eminently useful to an instruc¬ 
tor wishing to demonstrate this soft¬ 
ware’s special capabilities. Unfortu¬ 
nately the default setup (without the 
special features) reappears after the 
program has been exited, a decided 
disadvantage to instructors who want 
to demonstrate these setups in class. 

The tutorial also shows off this soft¬ 
ware’s capability for keeping visible 
track of recursive calls of a subpro¬ 
gram. But the program that the manu¬ 
al uses prints all 92 ways to place eight 
queens on a chess board without their 
attacking each other. If run in visible 
mode, it is agonizingly slow. 

All in all, beginning students would 
need supplementary material from the 
instructor for the tutorial to achieve 
its purpose. That supplementary ma¬ 
terial should contain instructions on 
how to stop running a program pre¬ 
maturely. 

Reference section. Here the reader 
finds details about the software in the 
areas of filing and editing, compiling 
and running, adjusting Dr. Pascal’s 
visibility features, and particular fea¬ 
tures of the Pascal language. 


Filing. This section contains a useful 
discussion of the relationship between 
a program in memory and its disk ver¬ 
sion. Beginners might need the discus¬ 
sion applied to their particular sys¬ 
tems (contrary to the manual, on 
VAX/VMS the older version of a pro¬ 
gram file is not renamed to .BAK). 

One feature in the “other options 
part” of the filing command seems 
very helpful for students doing course 
assignments. The student can keep a 
log file of whatever transpired in a 
program whose input/output was con¬ 
fined to the terminal. (Note, however, 
that this option is explained in a two- 
page addendum at the end of the 
manual.) 

Editing features. Most options con¬ 
nected with filing are explained well 
and using them is easy. Two excep¬ 
tions exist. The text explaining the 
uses of the nonprogram editor should 
be reworked for simplicity. So too 
should the commands needed to ter¬ 
minate such usage. It is not easy to 
figure out how to leave this mode 
when you are editing the same pro¬ 
gram you are trying to compile and 
run. And, while selecting the option 
“file list” lets you see current directo¬ 
ry files, its “directory mask” prompt 
will confuse beginners. 

The options connected with the 
procedure editor also work as de¬ 
scribed except for the one marked 
“print.” Selecting this command did 
not send the procedure being edited 
to the printer. Rather it produced a 
file named DPJHST.LST. This file 
could be sent to the printer through 
the system’s print command. 

In comparison to the VMS EDT ed¬ 
itor of the VAX, the Dr. Pascal editor 
offers a closer tie between the compil¬ 
er and the user’s program. But the re¬ 
placement of several EDT commands 


Before writing this review of Bor¬ 
land International’s newest release of 
Turbo Pascal (6.0), I reread my review 
of Turbo Pascal 4.0 that appeared in 
the July 1988 issue of IEEE Software 
(p. 105). I praised that release for its 
expanded power, speed, and versatili¬ 
ty. The big change then was the intro¬ 
duction of units that made modular 
programming really feasible. The user 


on the keypad with those peculiar to 
Dr. Pascal causes a bit of hardship. 

Limitations. An important warning 
regarding the VAX/VMS version of 
Dr. Pascal is that it uses A Z as its exit 
command from various parts of the 
editor. The editor is so intertwined 
with the compilation and running of 
programs that one cannot use A Z to 
end user input at the terminal (as is 
required by VMS). The only feasible 
remedy to such a shortcoming was to 
change the meaning of the “exit” 
command in the dpterm files (those 
that define the meanings of various 
Dr. Pascal commands for the terminal 
used) from A Z to some control se¬ 
quence not already defined. Technical 
support suggested A X to me, which 
works fine. This instance demon¬ 
strates that Dr. Pascal was not adapt¬ 
ed to the VAX/VMS environment as 
thoroughly as you would expect for 
released software. 

Summing up. The VAX/VMS ver¬ 
sion of Dr. Pascal is a highly useful 
piece of software for first-time Pascal 
students and their instructors. Howev¬ 
er, it is occasionally awkward to use 
and is not fully adapted to the VAX/ 
VMS environment. Instructors should 
make students aware of potential 
transition problems. 

Base VAX/VMS license fees for 
commercial and educational purposes 
are $800 and $400. MS/PC-DOS ver¬ 
sions for students cost approximately 
$35. 

Professional versions are available 
from Visible Software, Dept. IC, PO 
Box 7788, Princeton, NJ 02173. The 
student version is distributed by D.C. 
Heath and Co., 125 Spring St., Lexing¬ 
ton, MA 02173. 
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interface was also much improved. 
However, I regretted that the package 
did not include a sorely needed 
source-code debugger. 

Turbo Pascal 6.0 is another major 
stage in the evolution of this great 
programming language. Version 5.5 
had introduced object-oriented pro¬ 
gramming to Turbo Pascal. In 6.0, a 
language extension called Turbo Vi- 


Another major step in Turbo Pascal 

Curtis W. Swanson, California State University, Fullerton 
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sion expands OOP functions enor¬ 
mously. Turbo Vision is an object-ori¬ 
ented application framework and li¬ 
brary. Programs written in Turbo 
Vision inherit everything from mouse 
support, dialogues, menus, and over¬ 
lapping windows to automatic desktop 
management and an on-line help sys¬ 
tem. Obviously, such a basic program 
architecture can spare you many te¬ 
dious hours. Since Turbo Vision pro¬ 
vides a ready-made sophisticated user 
interface, you can spend your time 
creating the code unique to your ap¬ 
plication. 

One of the four manuals is devoted 
to Turbo Vision and serves as a good 
introduction to OOP. But the thick¬ 
ness of this manual proves that Turbo 
Vision is not as intuitively simple as 
Borland’s promotional materials 
might lead you to believe. It is defi¬ 
nitely not the sort of project that a 
newcomer to OOP would want to un¬ 
dertake. Other caveats apply as well. 
Turbo Vision is not just another li¬ 
brary or set of tools but an integrated 
application framework that demands 
that you play by its rules. You have to 
use its component object types as they 
were intended or not at all. This 
means, for example, that you must ac¬ 
cept Turbo Vision’s philosophy of 
screen design. Attempting to change 
the function and appearance of Turbo 
Vision to suit your particular needs is 
at best difficult and at worst futile. 

Turbo Vision is attractive, versatile, 
and robust — as you see when you 
first run the program. The user inter¬ 
face that greets you is the Integrated 
Development Environment (IDE) 
written in Turbo Vision. Its features 
include mouse support, multiple over¬ 
lapping windows, pull-down menus, 
a multifile editor that can process 
1-Mbyte files, clipboard functions, and 
an on-line hypertext help system that 
you can even paste into your applica¬ 
tions. 

This programming environment is a 
joy to use. The editor, compiler, and 
debugger are seamlessly integrated. 
The compiler is extremely fast: Bor¬ 
land claims an 85,000-lines-per- 
minute compilation speed, more than 
three times faster than Turbo Pascal 
4.0. As with previous versions, when 
the compiler encounters an error, it 
deposits you in the editor and high¬ 
lights the source code where the error 
occurred. You then correct the error 
and recompile. In the days when both 
compilers and computers were slower, 
such error-by-error compilation could 
be a major impediment to rapid pro¬ 
gram development. Now times are ac¬ 
ceptable. Logic errors in compiled 



Turbo Vision is not just 
another library or set of 
tools but an integrated 
application framework. 


programs can be corrected with the 
much-enhanced integrated debugger. 

The stand-alone debugger that is 
part of the professional package can 
handle even more complicated prob¬ 
lems. Besides the Turbo Debugger, 
the Turbo Pascal Professional in¬ 
cludes the Turbo Assembler and the 
Turbo Profiler. The Turbo Drive 
Compiler permits you to compile 
much larger programs by using ex¬ 
tended memory. 

The professional version retails for 
$299.95, while Turbo Pascal 6.0 lists 
for $149.95. The hardware required is 
a PC-compatible under DOS 2.0 or 
later with 256 Kbytes for the com¬ 
mand-line compiler and 512 Kbytes 
for an integrated environment. Disk 
space is 3.5 Mbytes to install the en¬ 
tire environment. The Turbo Assem¬ 
bler, Turbo Debugger, and Turbo 
Profiler require another 3.7 Mbytes of 
disk space 

The most substantial modification 
to the compiler itself is the introduc¬ 
tion of private fields and methods for 
objects. Now you can make specified 


fields and methods inaccessible out¬ 
side of the current unit (encapsula¬ 
tion). This capability is an important 
principle of OOP, but before the addi¬ 
tion of the private keyword it was not 
possible to enforce it. Turbo Pascal 
6.0’s improved heap manager also 
helps to prevent fragmentation. A 
built-in, in-line assembler is a great 
improvement over the INLINE state¬ 
ment. Although Turbo Pascal does 
not support Windows 3.0 or the Pre¬ 
sentation Manager, a Windows ver¬ 
sion is now available. 

The superior documentation should 
satisfy the entire range of needs from 
tutorials for the beginner to reference 
volumes for the professional. The on¬ 
line hypertext help system is immense¬ 
ly convenient and informative and per¬ 
mits the pasting of sample code 
directly into your program. 

Since the introduction of Version 
5.5, Turbo Pascal programmers could 
reap the benefits of OOP. But until 
now many of us have resisted learning 
new material. The evident advantages 
of Turbo Vision and other OOP fea¬ 
tures of 6.0 will surely lead to more 
professional-looking programs devel¬ 
oped in shorter time frames. The basic 
and professional versions are solid, 
robust packages that offer excellent 
value. 

Readers may contact Borland Inter¬ 
national at 1800 Green Hills Rd., PO 
Box 660005, Scotts Valley, CA 95067; 
(408) 438-5300. 
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Modula OS/2 Development System 

Giovanni Perrone, GP Systems 


Unlike many other software ven¬ 
dors who are hedging their bets on 
OS/2 products, Multiscope continues 
to expand its offerings. (Multiscope, 
formerly Logitech’s Software Tools 
Group, is now an independent com¬ 
pany.) The popular development tools 
for the Modula-2 language, Multi¬ 
scope/Logitech Modula-2, have been 
available in the DOS environment for 
quite some time. Now Multiscope of¬ 
fers an OS/2 implementation of the 
Modula-2 language in a complete de¬ 
velopment system. 

The Modula OS/2 Development 
System (MODS, if you’ll permit the 
acronym) is a nicely integrated set of 
programming tools that takes full ad¬ 


vantage of the OS/2 programming en¬ 
vironment. It has been implemented 
with the intention of providing a supe¬ 
rior language solution for OS/2 devel¬ 
opers. It combines MS-DOS compati¬ 
bility and the programming elegance 
of Multiscope/Logitech Modula-2 with 
the full functionality of OS/2. 

MODS provides a lot of software de¬ 
velopment capability for $549. It con¬ 
sists of the Modula OS/2 optimizing 
compiler with linker, an enhanced and 
fully integrated POINT editor, and the 
excellent Multiscope debuggers. It is a 
standard implementation of Niklaus 
Wirth’s Modula-2 language as defined 
in Programming in Modula-2, 3rd ed., 
Springer-Verlag, New York. 


July 1991 


83 






Be forewarned that MODS — un¬ 
like many other programming envi¬ 
ronments — does not contain a Modu¬ 
la-2 language tutorial or even a 
programming language reference sec¬ 
tion. The company’s basic assumption 
is that a user either already knows the 
Modula-2 language or is willing to 
learn it by supplementing MODS with 
other material. 

MODS offers many excellent pro¬ 
gramming examples, a complete set of 
syntax diagrams for the company’s im¬ 
plementation of the language, and a 
very effective transition into the new 
language environment. The Modula 
OS/2 developer’s guide takes you 
through the basics of the MODS com¬ 
pile, link, and run steps in the early 
chapters. You can perform these from 
either the OS/2 prompt or from within 
the POINT editor. The initial taste of 
POINT’S syntax-checking capability 
leaves you eager to explore this su¬ 
perb editor. By this time, you have 
quickly become familiar with the spe¬ 
cifics of the MODS development cy¬ 
cle. Now you are ready for some more 
complex program examples, which are 
provided along with the instructions 
to run them through the cycle. 

Programmers familiar with Pascal 
will also be happy to see that an entire 
chapter is devoted to presenting Mod¬ 
ula-2 from a Pascal perspective. The 
important differences are explained in 
detail and illustrated by examples. 

The compiler. The MODS compiler 
translates the Modula-2 source 
(ASCII text) code files (called mod¬ 
ules) into symbol files or linkable ob¬ 
ject files. The source modules are ei¬ 
ther definition (.DEF) or 
implementation or program (.MOD) 
modules. A DEF module defines all 
the identifiers it exports. The MOD 
module contains implementation de¬ 
tails of these exported identifiers. 

Each DEF module has a correspond¬ 
ing MOD module that uses the same 
file-name prefix (such as 
SAMPLE.DEF and SAMPLE.MOD). 

The compiler compiles a DEF mod¬ 
ule and generates a symbol (SYM) file, 
a compact and dated representation of 
the definition file. The symbol file is 
checked when an implementation 
(MOD) module is compiled. The cor¬ 
responding information is used to gen¬ 
erate a linkable object file. If errors oc¬ 
cur during compilation, a listing (.LST) 
file containing a list of the errors is also 
generated to aid debugging. 

There are about two dozen compil¬ 
er options available that are entered 
using the familiar “command-line- 
switch” technique. A handy table 


Multiscope is the first 
debugger designed 
specifically for OS/2 
development. 


shows all options, the values that turn 
them on and off, and the default val¬ 
ues for each. Options control such 
compiler actions as the mode of oper¬ 
ation for error message display, sym¬ 
bol file searches, listing-file genera¬ 
tion, emulation for an arithmetic 
coprocessor (the OS/2 compiler does 
not support in-line coprocessor code), 
compilation statistics, size optimiza¬ 
tion, reference (.REF) file generation 
for debugging, and more. The envi¬ 
ronment variable M2CFG lets you 
easily set the default options. A set of 
compiler directives is also available. 

The compiler produces a linkable 
object file that can be linked and exe¬ 
cuted in either OS/2 (protected) or 
DOS (real) mode. MODS includes a 
complete dual-mode Modula-2 stan¬ 
dard library and runtime support li¬ 
brary so that dual-mode applications 
can be developed. An exception is cit¬ 
ed for programs that use low-level (OS/ 
2 privilege) code, and guidelines are 
given to help you stay out of trouble. 

MODS uses the OS/2 Linker. After 
all modules constituting a program 
are compiled, the object files generat¬ 
ed are linked along with the MODS 
library object files to produce the exe¬ 
cutable program. 

By declaring a Foreign Definition 
Module, you can interface Modula-2 
programs with other languages such as 
C, Pascal, and assembler. The neces¬ 
sary techniques and conventions to 
support such mixed-language pro¬ 
gramming are fully explained. 

The editor and utilities. MODS in¬ 
cludes several useful utility programs. 
The M2MAKE utility builds batch 
files that streamline the compile-and- 
link process. M2DECODE decodes 
Modula-2 object files into text files 
that show disassembled code or data. 
M2CHECK helps avoid common pro¬ 
gramming errors by providing a listing 
file based on the analysis of Modula-2 
source files. M2XREF generates 
cross-reference information tables 
from text files such as Modula-2 


source files. M2VERS helps track and 
control different versions of a pro¬ 
gram. POINT, an excellent editor that 
I found especially well-suited to the 
MODS environment, has also quickly 
become my favorite general-purpose 
editor. 

The first thing I like about POINT 
is that it is much faster than any other 
editor I have ever used, in any envi¬ 
ronment. The next thing is that it can 
be configured for both OS/2 and 
DOS. POINT is an efficient editor, 
crisp and light on its feet; but it is also 
very effective, full-featured and easy 
to use from either mouse or keyboard. 
It is completely customizable. For 
MODS, an M2Assist POINT exten¬ 
sion integrates the editor with MODS. 
When you install POINT with MODS, 
an M2Assist pull-down menu lets you 
check syntax, compile (in the OS/2 
foreground or background), examine 
errors, link, and run programs from 
within the POINT editor. 

Debuggers. Multiscope is the first 
debugger designed specifically for 
OS/2 development. Even though it is 
now included as part of MODS, it is 
packaged and sold separately. It lets 
you debug OS/2 Presentation Manag¬ 
er applications. A multiple-language 
debugger, it supports all OS/2 compil¬ 
ers that generate standard Code View 
OS/2 debugging information. Multi¬ 
scope actually includes four debug¬ 
gers: OS/2 Presentation Manager 
Run-Time, Presentation Manager 
Post-Mortem, Text Mode Run-Time, 
and a Text Mode Post-Mortem. This 
span of debugging power and flexibili¬ 
ty should satisfy most OS/2 scenarios. 

The Run-Time Debuggers let you 
monitor program execution with 
breakpoints and watchpoints (memo¬ 
ry and symbolic), step program execu¬ 
tion, modify memory and data con¬ 
tents, suspend and resume execution 
of threads, display all breakpoints and 
watchpoints, and even graphically dis¬ 
play data structures. 

The Post-Mortem Debuggers let 
you symbolically analyze the state of a 
“dead” program. You must prepare 
your program for post-mortem debug¬ 
ging by running it with the Multiscope 
Monitor Execution Dump utility. 

MED monitors the executing program 
without interference and captures a 
“dump” file if it crashes. The Post- 
Mortem Debugger lets you examine 
the dump file to find the problem. 

The tutorial is a comprehensive but 
crisp 30 pages. It concentrates on the 
Presentation Manager Real-Time De¬ 
bugger and progressively builds your 
knowledge (and interest). 
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Two debugger interfaces — Text 
Mode and Presentation Manager — 
share many features and support the 
same basic operations. The Graphics 
Data window is only available in Pre¬ 
sentation Manager mode. The two in¬ 
terfaces differ in screen displays and 
input collection. Other differences oc¬ 
cur when manipulating windows, us¬ 
ing menus, and executing commands. 
The Text Mode screen emulates the 
Presentation Manager display as 
closely as possible. The Text Mode in¬ 
terface uses tiled (rather than overlap¬ 
ping) windows. Most users will prefer 
to use the Presentation Manager in¬ 
terface, but the Text Mode interface is 
available (and recommended) if 
screen conflicts occur. 

Both interfaces are convenient to 
use. The availability of multiple win¬ 
dows gives a new dimension to debug¬ 
ging. Multiscope is certainly not the 
first to use them. But the availability 
of so many windows that are so handy 
to manipulate is a Multiscope debug¬ 
gers forte. 

I found the Presentation Manager 
implementation especially appealing 
and effective. The windowing and 
menuing operations become almost 
second nature, smooth and natural 
with mouse and keyboard control in¬ 
terchangeable and equally convenient. 
The entire spectrum of operations is 
point-and-shoot — providing a tool 
that lets you focus on the problem to 
be solved rather than on the tool. 

Wrapping up. MODS integrated 
features let you fully exploit the ad¬ 
vantages of the OS/2 programming 
environment. And Multiscope claims 
that their Modula-2 language imple¬ 
mentation does all that C does and 
more. 

Multiscope/Logitech Modula-2 is 
popular in the educational arena. Sim¬ 
ilar to Pascal, which has a large fol¬ 
lowing in the academic community, it 
can also be used as a first language to 
learn programming and adds a rich 
variety of professional software devel¬ 
opment features. It is available for 
DOS and OS/2 now and will soon be 
released (Version 4.0) for developing 
Windows 3.0 applications. 

Multiscope supports MODS with a 
technical support hotline, a toll-free 
customer service hotline, an electronic 
conference on the Byte Information 
Exchange, and an unconditional 30- 
day, money-back guarantee. 

Multiscope Inc. can be reached at 
1235 Pear Ave., #111, Mountain View, 
CA 94043; (800) 999-8846. 
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Review notes 


Monologue 2.0. This impressive 
software package for IBM PCs and 
compatibles does not require special 
hardware for speech generation. A 
software-generated voice is directed 
to the built-in computer speaker or 
to one of a number of speech acces¬ 
sories. However, when tested on a 
variety of computers, Monlogue of¬ 
ten produced different results. 

Monologue uses a rule-based al¬ 
gorithm to convert text to speech 
and can use a table-based tech¬ 
nique for handling words that don’t 
follow phonetic rules of pronuncia¬ 
tion. Thus, you can save your own 
preferred pronunciations of words 
and abbreviations in the table. 

With three distinct modes of opera¬ 
tion (searching, selecting, and 
speaking), you can choose any text 
that appears on the computer 
screen and transform it to speech. 

The file TALKDRVD.SYS on 
the distribution disk can be used in 
CONFIG.SYS to create a DOS de¬ 
vice @TALK. You can thus use 
@TALK as the name of the output 
text file from within your own pro¬ 
grammed application. Another sup¬ 
plied program uses this feature to 
speak any displayed text file. 

Monologue was tested on an 
IBM PC 486, a Compaq 286, a 
Toshiba 286, a no-name 286 clone, 
and a Toshiba T1000 (8086). None 
of these machines has a Mono¬ 
logue-supported speech accessory. 
Except in the Compaq and no¬ 
name clone, the speakers did not 
deliver audible volume. We had to 
use an amplifier connected to the 
output of the internal computer 
speaker. Operating this way, Mono¬ 
logue worked just fine. (Even 
though the sound could be heard 
from the other two machines, 
sometimes it wasn’t loud enough.) 

We also tested the package using 
Covox’s Speech Thing, a small DC- 
powered integrated amplifier/ 
speaker that connects to the PC’s 
parallel port. By reinstalling Mono¬ 
logue, the Speech Thing provided 
excellent sound for all machines ex¬ 
cept the T1000. First Byte’s techni¬ 
cal support line told us that because 
of the slow clock rate of the T1000 
(4.77 MHz), Speech Thing does not 
work properly — it actually stut¬ 
ters! Without Speech Thing, Mono¬ 


logue spoke properly on the T1000, 
except it was almost inaudible. 

Monologue’s “speaking” of text 
files was really interesting. It has a 
special option for speaking on¬ 
screen Lotus 1-2-3 spreadsheets. 
When the package is installed as a 
TSR, you can use pop-up options 
to select tone, speed, and pitch for 
different “sound qualities.” When 
you vary these parameters, differ¬ 
ent kinds of human-like voices 
speak, including a female, midlevel 
voice. Unfortunately, the speech 
sometimes became “tongue-tied” 
at this level. 

Monologue is an interesting piece 
of software that can serve as the ba¬ 
sis for a new dimension of computer 
output. With the advent of multime¬ 
dia computing, audio will be the 
first and easiest multimedia exten¬ 
sion to add to conventional dis¬ 
played output. First Byte’s software 
has already been licensed by a num¬ 
ber of audio-output-device vendors. 
With the multimedia version of Mi¬ 
crosoft’s Windows expected some¬ 
time later this year. Monologue, op¬ 
erating alone or bundled/integrated 
with other vendors’ hardware, 
should be a very exciting utility. 

System requirements are an IBM 
PC with 384-Kbyte memory (640 
Kbytes recommended) and MS 
DOS 3.0 or higher. The $149 pack¬ 
age supports Covox Speech Thing; 
Street Electronics’ Echo PC+, MC, 
or Echo 1000; Creative Labs’ 

Sound Blaster; IBM ACPA; and 
Speech Card Hearsay’s 100 and 
500; and Tandy 1000 SL, TL, and 
2500 computers; and the IBM PS/1 
audio and graphics cards. 

Readers may contact First Byte 
at 3100 South Harbor Blvd., Ste. 
150, Santa Ana, CA 92704; (714) 
432-1740. 

— Qing Zhuang, MOCO Inc., 
and Sorel Reisman, California State 
University, Fullerton 
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Moderately priced accounting 

systems. Service Industry Account¬ 
ing from Brown-Wagh Publishing 
is an integrated business solution 
for professionals, trade persons, 
and small manufacturers. It is 
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geared to anyone selling skill, ex¬ 
pertise, or products off the shelf. 

The package saves you time by 
automatically updating all ac¬ 
counts. Receivables, payables, in¬ 
ventory, job records, and general 
ledger are posted in one step. 

The $495 program requires an 
IBM PC, a hard disk, and a print¬ 
er that can print 132 characters us¬ 
ing the IBM character set. 

Pacoli 2000 from M-USA Busi¬ 
ness Systems consists of eight ac¬ 
counting modules in one: general 
ledger, accounts receivable, ac¬ 
counts payable, inventory control, 
purchasing, billing, budgeting, and 
auditing. It supports the cash- and 
accrual-basis, inventory-based 
business, and service-based busi¬ 
ness accounting systems. 

The package, which comes with 
a video cassette for explaining a 
limited set of accounting terms, can 
support up to 999 companies and is 
network ready. Printing invoices 
and checks requires special trac¬ 
tor-feed forms available from the 
company. Laser printer support is 
limited. A mouse is optional. 

Brown-Wagh Publishing is lo¬ 
cated at 16795 Lark Ave., Ste. 

210, Los Gatos, CA 95030; (408) 
378-3838. M-USA Business Sys¬ 
tems Inc. is located at 18111 Pre¬ 
ston Rd., Ste. 500, Dallas, TX 
75252; (214) 931-0024. 

— T.L. (Frank) Pappas, Aweb 
Software Technology 
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A Postscript printer with Laser 
Jet emulation. Okidata’s Oki La¬ 
ser 840, which sells for $2,999, is 
an 8-page-per-minute Postscript 
printer that also offers Laser Jet 
II and Diablo 630 emulation. The 
printer, with 2-Mbyte standard 
RAM, comes with a single 
200-sheet letter-sized paper tray. 

A 2-Mbyte upgrade and an op¬ 
tional second paper tray can be in¬ 
stalled. Other available trays in¬ 
clude legal, executive, and 
envelope. 

The printer supports manual in¬ 
sertion of single sheets of paper 
and single envelopes. It also ac¬ 
commodates transparencies and 
labels. 


The 840’s separate toner cartridge 
doesn’t include the drum. Each car¬ 
tridge, which sells for $33, lasts for 
about 2,500 pages, although you’ll only 
get 1,500 pages from the first one. The 
drum life is from 11,500 to 15,000 pag¬ 
es. You will get the lower rate if you 
print many short documents, say, two 
to three pages apiece. The drum re¬ 
placement kit is over $200. 

Although printers using the car¬ 
tridges found in the Laser Jet II, IIP, 
or III can be recycled at substantial 
savings (see next “Review note”), 
that’s currently not an option for Oki 
Laser 840 users. However, I expect 
this to change in the next few months. 

Physically, the 840 is average. It 
weighs 37 pounds and is 8,5 inches 
high and 17.7 inches in both depth and 
width. The paper trays are at the front 
of the printer, next to the membrane 
controls. These controls also run the 
easy-to-use built-in menu. Slots for 
two font cartridges appear just below 
the controls. The power switch is awk¬ 
wardly placed at the rear of the left- 
hand side, but that’s the only thing 
about this printer that you won’t like. 
The top paper feed delivers the paper 
face down, but the rear paper feed — 
used for envelopes, labels, and trans¬ 
parencies — delivers face up. 

In native Postscript mode, the 840 
supports the standard 35 resident 
Postscript fonts. Built-in support for 
RS-232C serial, Centronics parallel, 
RS-422A serial, and Appletalk inter¬ 
faces allows the 840 to be used in most 
systems. 

In Laser Jet emulation, the printer 
supports four basic font types: Couri¬ 
er, Helvetica, Line Printer, and Times 
Roman. Courier and Line Printer can 
also be printed in landscape. Courier 
comes in 10 and 12 points. Times Ro¬ 
man supports those sizes as well as 8 
point. Line Printer can only be used at 
8.5 points, while the sole Helvetica 
setting is 14.4 points. Laser Jet emula¬ 
tion also supports 39 symbol sets. 

Diablo 630 emulation is much more 
limited, supporting only Courier at 12 
points in portrait or landscape mode. 
The emulation also supports 15 sym¬ 
bol sets. 

I tried the Postscript capability and 
the Laser Jet emulation with a variety 
of programs. Typical programs such as 
Microsoft Word and Excel worked 
fine, as did Tex (pronounced “teck” 
and frequently typeset as “T E X”) and 


several graphics programs. The docu¬ 
mentation, which is very good, 
even includes a description of the 
Laser Jet and Diablo commands. 

One thing I miss with this print¬ 
er is a program that would let us¬ 
ers switch between emulations. I 
may get around to writing one, but 
right now I just use the menus 
from the control panel. 

This printer is so versatile that it 
is the only one I use. My Laser Jet 
IIP with its Pacific Page Postscript 
emulation sits in a corner in case I 
ever have a problem with the 840. 
Based on my past experiences with 
Oki Laser printers — both laser 
and dot matrix — the only time I’ll 
need the IIP is when I don’t have 
time to replace a drum on the 840. 

If you can find another printer 
with these features at a better 
price, as inexpensive to maintain, 
and as reliable to operate, buy it! 

If not, consider the Oki Laser 840. 
You won’t regret it. 

Readers can contact Okidata at 
532 Fellowship Rd., Mount Laurel, 
NJ 08054; (800) 654-3282. 

— T.L. (Frank) Pappas, Aweb 
Software Technology 
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Save money and the environ¬ 
ment: Recycle toner cartridges. 

Replacing the toner cartridge is 
the biggest expense in using a laser 
printer or copier. The discounted 
price for one cartridge for the La¬ 
ser Jet IIP is about $93. For the 
Laser Jet II and III series, prices 
jump to about $114 and $100, re¬ 
spectively. As you can see, car¬ 
tridge replacement can quickly ex¬ 
ceed the original purchase price of 
a laser printer. 

One way to minimize replace¬ 
ment costs is to recycle used car¬ 
tridges. But is it safe to recycle? 

Does it have any other benefits? 

To find out, I called the Ameri¬ 
can Cartridge Recycling Associa¬ 
tion, a nonprofit organization. 
ACRA, which can be reached at 
(305) 539-0701, will send you infor¬ 
mation about cartridge recycling 
and a list of recyclers near you. 

To get an idea of the cost of re¬ 
cycling, I contacted Office Special¬ 
ty Supplies at (800) 782-8668. For 
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$54.95 each, they pick up your old 
Laser Jet cartridges and refurbish 
them. The cost includes pickup and 
return through UPS. 

Like most recyclers who deal 
with end users, Office Specialty 
Supplies farms out the work to a 
third party because the demand 
has become too great. It chose the 
American Laser Cartridge Ex¬ 
change in North Brunswick, New 
Jersey, which only does business 
with dealers. ACRA’s literature 
describes how recycling is done, 
but I wanted to evaluate the quali¬ 
ty of the procedure myself. When 
Office Specialty Supplies arranged 
a visit for me to North Brunswick, 

I found the company to have a very 
professional approach. 

Some people are wary of recy¬ 
cling because of a drill-and-fill ap¬ 
proach some dealers used to use. A 
hole was drilled into the cartridge 
and then filled with toner that 
wasn’t always of the best quality. 
The hole was either taped or 
plugged shut. But drilling left shav¬ 
ings in the toner, and sometimes 
the hole would open, letting toner 
and shavings spill into the printer, 
creating a mess and possibly dam¬ 
aging the printer. 

Drill and fill is no longer used — 
at least not by ACRA members — 
so it is not a problem. Instead, the 
cartridge is first tested to deter¬ 
mine whether the drum needs to 
be replaced. Typically, 22 percent 
of the cartridges need a new drum. 
The cartridge is disassembled by 
removing a few screws and pins. 
The excess toner hopper is emptied 
and vacuumed. 

Functioning drums are cleaned. 

If this is the first time for cartridge 
recycle, American Laser Cartridge 
Exchange and other companies ap¬ 
ply a process called anakenesis to 
the drum to coat it with a special 
liquid, letting it dry slowly. This 
process allows the drum to be recy¬ 
cled five to eight times. New toner 
is added and the cartridge is reas¬ 
sembled. The company, which tests 
the cartridge after reassembly, 
claims that only 1 to 11/2 percent 
of its recycled cartridges have 
problems, compared to 3 percent 
for brand new cartridges. 

According to the company, which 
currently processes about 30,000 


cartridges a month, most large recy¬ 
clers approach their work in the same 
way, although some details may vary. 
Most of these companies seemed con¬ 
cerned about recycling of materials as 
well. For example American Laser 
Cartridge Exchange uses specially de¬ 
signed cardboard packaging rather 
than foam to pack the recycled 
cartridges.The impact on the environ¬ 
ment when recycling does not occur is 
enormous.Of the 16 million laser print¬ 
er cartridges used each year, an esti¬ 
mated 14 million are discarded and 
wind up in land fills. Recycling can put 
a major dent in this waste. 

Although recognizing the benefits 
of recycling, some people are afraid 
that using a recycled cartridge would 
void their warranty. First of all, a car¬ 
tridge recycled by a reputable dealer 
can’t void your warranty. It’s illegal! 

In fact, Hewlett-Packard wants to 
know if any HP dealer tells you other¬ 
wise. If your recycler can’t help settle 
a dispute, ACRA usually can. If not, 
ACRA has an HP contact that can. 

I’m convinced that recycling cartridg¬ 
es is safe, cost effective, and environ¬ 
mentally sound. I’m going to take ad¬ 
vantage of it. How about you? 

— T.L. (Frank) Pappas, Aweb Software 
Technology 
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VGA-TV. If you want to use high- 
resolution color images from your 
IBM PC on an ordinary TV, then 
VGA-TV is for you. This super video 
graphics adapter board from Willow 
Peripherals extends your computer’s 
display to a television monitor in all 
resolutions up to 640 x 480 with 256 
colors. It offers full VGA compatibili¬ 
ty with either standard or multisynch- 
ing monitors. You can also direct the 
signal to a VCR and tape the images 
as they display on TV. 

I tested VGA-TV with a 486/25 
equipped with a Sony Trinitron multi- 
synching monitor. A Panasonic video 
color monitor served as the equivalent 
television set with video input. I in¬ 
stalled the VGA-TV card in a full-size 
slot. To get the card to run properly, I 
removed the installed VGA card and 
selected the suitable default graphics 
mode using the jumpers on the VGA- 
TV board. For example, if I wanted to 
set the computer to boot using the 


NTSC display signal mode rather 
than VGA (assuming I wanted to 
use a TV as the monitor), I had to 
install one set of jumpers. 

According to the manual, leav¬ 
ing the jumper unconnected is 
supposed to boot up the system in 
VGA mode, but it didn’t work for 
me. Fortunately, this problem 
didn’t keep me from testing the 
three options (multisynching mon¬ 
itor only, television only, and both 
monitor and TV). Using the sup¬ 
plied software, I easily switched to 
and from NTSC and VGA (black- 
level video on TV). 

I next installed the VGA soft¬ 
ware driver for Windows 3.0 from 
a company-supplied list of drivers. 
Windows in 800 x 600-pixel mode 
with 16 colors worked just fine but 
didn’t have colored icons. I found 
that the Sigma Designs VGA driv¬ 
er for the same resolution produ¬ 
ced color icons (interestingly 
enough, the boards use the same 
graphics chip). 

Graphics programs worked very 
well with no compatibility prob¬ 
lems. I ran two VGA graphics 
demos under NTSC. Both screens 
presented smooth, colorful pic¬ 
tures. Curves and text were not so 
sharp as those on the monitor us¬ 
ing standard VGA mode because 
of the limitations imposed by 
NTSC (as opposed to VGA). Ac¬ 
tually, even on the monitor, 80- 
column text under NTSC resem¬ 
bles CGA text. However, the 
problem won’t keep you from ex¬ 
ploring your video options, since 
you can obtain easier-to-read 
characters by using 40-column text 
on your TV. If you use the multi¬ 
synching monitor, you can simply 
set the output of VGA-TV to 
VGA signal mode to sharpen text. 

After performing limited tests, I 
agree that VGA-TV works as ad¬ 
vertised. The extended video out¬ 
put offers a versatility you won’t 
find on other boards at this price 
($499). If you need NTSC along 
with super VGA functions, VGA- 
TV offers a reasonable choice. 

Readers can contact Willow Pe¬ 
ripherals Inc., 190 Willow Ave., 
Bronx, NY 10454-9967; (212) 402- 
0010; fax (212) 402-9603. 

— Qing Zhuang, MOCO Inc. 
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Macintosh System 7 

operating system Manufacturers offer range of 

upgrade RISC products 


Apple Computer’s.System 7 fea¬ 
tures include Truetype, improving 
type quality at any size; File Sharing, 
allowing users to share designated 
items; Finder, enhancing search op¬ 
tions; Virtual Memory, expanding 
availability of computer memory; and 
Multitasking, allowing users to work 
with multiple applications and to per¬ 
form several tasks concurrently. 

Two System 7 upgrade products are 
available. A personal upgrade kit for 
single computers costs $99, and a 
group upgrade kit for an entire orga¬ 
nization costs $349. 

Current purchases of Macintosh 
computers will include a coupon for a 
free System 7. Future Macintosh sys¬ 
tems will include the System 7 package. 

Major developers, including Ash- 
ton-Tate, Adobe Systems, Microsoft, 
Word Perfect, Novell, Spyglass, and 
Ventura, offer applications compati¬ 
ble with System 7. 
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Epson adds fonts 
and features 

Epson America’s enhanced versions 
of three of its dot matrix printers, the 
LQ-510, LQ-850, and LQ-1050, in¬ 
clude additional fonts, automatic 
single-sheet loading, expanded front 
control panel, and, on the LQ-510, 
faster print speeds. 

Epson says that the LQ-510, a 24-pin, 
80-column printer, can now produce up 
to 192 cps in draft mode and 64 cps in 
letter-quality mode. It sells for $499. 

The LQ-850, an 80-column printer, 
and the LQ-1050, a 136-column printer, 
have retail prices of $749 and $1,099, re¬ 
spectively. Both printers are rated at up 
to 300 cps in superdraft mode and 98 
cps in near-letter-quality mode. 
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Upgradable to, upgradable from 

According to Digital, their DEC- five different graphics subsystems 
station 5000/100 Unix-based re- via the Turbochannel I/O bus, providing 

duced instruction-set computers users with a range of solutions from 
protect against technological obso- simple 2D to complex 3D graphics 
lescence in two ways. They have a and multiscreen configurations, 
removable CPU daughtercard that Applications include financial trad- 
can be replaced as more powerful ing, technical publishing, computer-aided 
processors become available, and software engineering (CASE), mechani- 
the DECstation 5000 workstations cal computer-aided design (CAD), elec- 
incorporate key elements of the trical computer-aided design (ECAD), 
ACE (Advanced Computing Envi- scientific modeling, mechanical modcl- 
ronment) standards. ing, scientific visualization, and graphics 

ACE confirms the company’s art design, 
commitment to open systems Both systems come with the industry- 

throughout its product spectrum. standard OSF/Motif graphical user in- 
Digital says that users can employ terface. 

their DEC Unix systems with ACE List prices for the new workstations 
products in the future. begin at $6,495. 

Both the DECstation 5000/120 

and the 5000/125 models support Reader Service 37 


Mips offers three 33-MHz systems 

Mips Computer Systems has the RC3350 is a deskside server 

added a workstation and two serv- with VME expansion capabilities, 
ers to its desktop and deskside se- and, according to Mips, is appropri- 
ries. The systems contain the 33- ate for multiuser and client/server 
MHz Mips R3000A microprocessor. applications. The RC3350 offers 
The Magnum 3000/33 worksta- 26.5 Specmarks of performance, 
tion reputedly delivers 25.1 Spec- and starts at $36,500. The base con- 
marks, is suited for commercial figuration includes 16 Mbytes of 
and technical environments involv- ECC memory, a 328-Mbyte SCSI 
ing computer-aided engineering, disk drive and a 150-Mbyte 1/4- 
graphical data analysis, and office inch cartridge tape drive, 
automation, and has a base price of The system can be expanded to 
$10,990. 128 Mbytes of ECC memory, 4 

The RC3330 Riscomputer entry- Gbytes of disk storage in the main 
level server, running at 25.1 Spec- cabinet, and up to 12 Gbytes with 

marks and supporting 8 to 128 an expansion cabinet (I/O via two 

Mbytes of memory and up to 6 VME slots). 

Gbytes of disk capacity, supports The 33-MHz desktop worksta- 

work groups using office automa- tion and server are also available as 
tion and software development ap- board upgrades to customers with 
plications. Its base configuration 25-MHz desktop systems, 
starts at $11,990. 

For medium-sized work groups, Reader Service 38 
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IBM builds more powerful AS/400s 


IBM is replacing the current Appli¬ 
cations System/400 (AS/400) line with 
11 new processors, including one that 
outperforms the previous most power¬ 


ful AS/400 processor by up to 2.8 
times, according to the company. 

The new models offer system 
price/performance improvements of 


Workstation for real-time applications 


The Model 7100 workstation from 
Aydin Control serves high-perfor¬ 
mance and open-architecture moni¬ 
toring and control graphics applica¬ 
tions. 

The system uses a RISC processor 
for real-time applications. 

Graphics include 1,280 x 1,024 dis¬ 
play resolution, 12 display planes 
(double buffering), and color CRT 
monitors. 

The system features full ABI/BCS/ 
OCS compliance based on the Motor¬ 
ola 88000 processor, a real-time ker¬ 
nel running AT&T Unix 5.3.2, TCP/IP 


communications on Ethernet, 
VME/VSB bus user expansion 
slots, and multiplexed full-function 
keyboards and cursor control. 

The 7100 comes in tower or 
rack-mount enclosures and inter¬ 
faces with operator peripherals up 
to 300 ft. from the chassis for con¬ 
trol room applications. 

The base system price, including 
software, a 19-inch color CRT, a 
90-Mbyte hard disk, and a 150- 
Mbyte tape drive, is $35,100. 
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Sun Sparcompilers improve performance 


Sun Microsystems’ new releases in 
the Sparcompiler family of languages 
improve Sparc performance by 10-18 
percent, according to SPEC bench¬ 
marks. 

The new Sparcompilers include Sun 
C 1.1, C++ 2.1, Fortran 1.4, and Pascal 
2.1, each priced at $2,000 per user li¬ 
cense; Sun Modula-2 2.3, priced at 
$2,200 per user license; and NSE 1.3 
at $10,800 for a 20-user license. 

Sun’s Sparcworks developer tools. 


More RISC power 

Silicon Graphics has extended its 
Iris Power Series by introducing the 
Iris 4D/400 product family, including 
the 4D/480 project supercomputer. 
The company claims that this system 
is the highest performance RISC 
available, delivering 286 MIPS (mil¬ 
lion instructions per second), 70 
Mflops (million floating-point opera¬ 
tions per second), and a SPEC 
throughput rating of 159. 

Applications for the 4D/400 series 
include computer-aided molecular de¬ 
sign, computational fluid dynamics, fi¬ 
nite element analysis, signal process- 


bundled with Sun C, C++, Fortran, 
Pascal, and Modula-2, consist of 
dbx and dbxtool for debugging, and 
Sun Sourcebrowser, a window- 
based search tool. Sparcworks 
tools, integrated with other Sun 
products such as Open Windows, 
File Manager, Mail Tool, and other 
deskset tools, provide a visually 
consistent desktop environment. 
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ing, physics, and simulation. 

The 4D/400 Scries uses the Mips 
R3000A chip and has 9 Mbytes of 
cache memory. The symmetric mul¬ 
tiprocessing systems come in two-, 
four-, or eight-CPU configurations. 

Server base prices range from 
$64,900 for the two-processor 4D/ 
420S to $164,900 for the eight-pro¬ 
cessor 4D/480S. Graphics system 
base prices range from $94,900 for 
the 4D/420GTX to $224,900 for 
the 4D/480VGX. 
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up to 50 percent over predecessor 
models. 

The AS/400 D model processors 
provide a 30- to 60-percent increase in 
relative performance over current B 
and C models. Performance gains re¬ 
sult from faster internal processing, 
larger main memory, and increased 
disk storage capacity. 

Model D80 uses two closely coupled 
parallel processors, providing in¬ 
creased system performance and al¬ 
lowing for growth. 

Purchase prices for the 11 AS/400 D 
models range from $16,250 to $749,000 
for base models, with operating sys¬ 
tems. For an upgrade charge, users 
may convert their B and C models to 
the new D models at their premises. 

IBM has also announced expanded 
support for the Open Systems environ¬ 
ment: Version 2 of Operating System/ 
400, enhanced systems management, 
streamlined business printing, a desk¬ 
top publishing system, a new optical 
storage system, enhanced image tech¬ 
nology, and productivity enhancements 
for the AS/400 as server. 
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TI brings out its 486/25E 

Texas Instruments’ 486/25E com¬ 
puter supports up to 16 users and runs 
the SCO Xenix, Unix, and MS-DOS 
operating systems. 

The computer is built around an In¬ 
tel 486 processor running at 25 MHz, 
has an on-chip 80387 numeric copro¬ 
cessor, and includes 8 Kbytes of on- 
chip cache memory. 

The standard 4 Mbytes of memory is 
expandable to 16 Mbytes on the pro¬ 
cessor board, with another 32 Mbytes 
available through expansion slots. The 
system has a seven-slot Extended In¬ 
dustry Standard Architecture bus with 
support for 8-, 16-, or 32-bit cards. 

Other seven-slot TI workstations can 
be upgraded to 486/25E performance 
by exchanging the processor board. 

The 486/25E includes either a 5.25- 
in., 1.2-Mbyte or a 3.5-in., 1.44-Mbyte 
floppy disk drive. A second floppy 
drive and a 40- or 150-Mbyte cartridge 
tape backup drive can be installed as 
options. 

The 486/25E costs $8,415, and the 
486/25E upgrade is $2,745. 
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VAX voice applications enter 
computing mainstream 

Voicemail as VAX/VMS application 


Voicesoft Corp.’s Voicemail is 
part of Digital’s All-in-1 Phase II 
program for office computing. Ac¬ 
cording to Digital, maintenance 
and support are as easy as with 
any other VAX/VMS application. 
Voicemail can be linked with and 
run simultaneously with other ap¬ 
plications on the network. Special 


Digital provides specifications 
for CD A/ Audio, an extension of 
the Compound Document Archi¬ 
tecture (CDA) component of 
NAS. (NAS is Digital’s implemen¬ 
tation of open systems, based on 
industry standards.) 

The CDA architecture enables 
text, graphics, images, audio and 
voice information to be shared in 
revisable format among applica¬ 
tions on different systems, includ¬ 
ing VMS, Unix, DOS, Apple 
Macintosh, and OS/2. 

The CD A/Audio specifications, 
publicly available from the CDA 
program office, will enable devel- 

Telecommunications 
voice applications 

Digital says its voice offerings 
can also enhance telecommunica¬ 
tions services, providing voice- 
based directory assistance and 
voice mailbox, which can be linked 
to billing systems. 

Reader Service 44 

Voice processing in 
commercial applications 

Computer Associates’ Version 
2.0 of CA-DB:Expert/Voice offers 
voice processing for commercial 
applications such as banking-by¬ 
phone and customer order-entry 
systems. Version 2.0 is available in 
beta release. Prices range from 
$3,675 to $117,600, depending on 
configuration. 
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features selectively receive mes¬ 
sages and define file folders to 
store messages. 

Voicemail with complete soft¬ 
ware configurations is priced from 
$10,000. 
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opers to add audio-interchange ca¬ 
pabilities to their applications. A 
nondisclosure agreement is not re¬ 
quired for distribution to software 
developers. 
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Digital’s Multiline DECvoice, 
combining three voice-processing 
capabilities — voice digitization for 
storage, voice recognition, and text- 
to-speech synthesis — into one 
module, enables VAX systems to 
act as “voice servers” for some ap¬ 
plications in a network without be¬ 
ing dedicated to voice processing. 

The module, available for VAX 
4000 and MicroVAX 3000 families, 
is priced at $9,410, including a T1 
telephony interface. Preconfigured 
VAX 4000-300 systems with Multi- 
line DECvoice start at $32,000 for 
a complete eight-channel system. 
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Audiokit for publishers 

Audiotechs’ Audiokit line of 
voice application software tools is 
suited for newspaper and magazine 
publishers wishing to develop 
“talking classifieds” and other in¬ 
teractive voice bulletin-board ap¬ 
plications. 

Audiokit, available for VAX/ 
VMS systems, is priced at $800 per 
telephone line. 
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IBM adds i486 SX to PS/2 

IBM’s PS/2 Models 90 and 95 SX 
486 incorporate 32-bit, 20-MHz pro¬ 
cessors with 32-bit data paths and of¬ 
fer an optional upgrade to include the 
PS/2 Math Coprocessor 487 SX (20 
MHz). 

As with other members of the 90 
and 95 families, the SX systems can be 
upgraded to future i486 technologies 
by installing new processor-complex 
cards when they are developed. 

The SX systems have the PS/2 Mi¬ 
cro Channel SCSI adapter and a 32- 
bit bus master that includes a 512- 
Kbyte cache. They come standard 
with 4 Mbytes of memory, expandable 
to 32 Mbytes of high-speed, 70-nano¬ 
second memory on the system board. 

The desktop 90 SXs are configured 
with either an 80-Mbyte SCSI fixed 
disk (SX-0G5) or a 160-Mbyte fixed 
disk (SX-0G9). 

The floor-standing 95 models (SX- 
0G9 and SX-0GF) have six available 
expansion slots and seven storage 
bays to handle complex network-serv¬ 
er tasks. 

The 95 SX-0G9 is configured with a 
160-Mbyte SCSI fixed disk, and the SX- 
0GF has a 400-Mbyte SCSI fixed disk. 

Options for the 486 90 and 95 SX 
models include 80-, 160-, 320-, and 
400-Mbyte SCSI fixed disks. 

The 90 SX-0G5 and -0G9 cost 
$8,345 and $8,945, respectively. The 
95 SX-0G9 costs $9,995, and the 95 
SX-0GF is $12,695. 
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Real-time tools for 
graphics 

Quinn-Curtis’ Real-Time Graphics 
and Measurement/Control Tools form 
the kernel for developing graphics- 
based programs that perform process 
control, data logging, and instrument 
interface operations. 

Graphics routines include scroll, 
sweep, logic graphs, bar graphs, meters, 
gauges, and annunciator displays. 

Measurement/control routines in¬ 
clude proportional-integral-derivative 
(PID) control, thermocouple lineariza¬ 
tion, curve fitting, and Fourier analysis. 

Versions of the tools are available 
for Turbo Pascal 5.x and 6.x, Turbo C 
2.x, C++, Microsoft C 5.x and 6.0, and 
Quick C 2.0. 

The function library costs $200. 
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Audio added to text, graphics, images 


Voice servers 
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The second international 
workshop on raster imaging 
and digital typography 

Boston, October 15-16,1991 


Chair: Robert A. Morris (UMB) 
Vice-chair: Roger Hersch (EPFL) 
Proceeedings co-editor: 

Jacques Andre (IRISA) 


Sponsors: The University of Massachusetts at Boston and 
the IEEE Computer Society, with the cooperation of ACM 
SIGGRAPH. Additional support: Adobe Systems Inc., Agfa 
Corp., Bitstream Inc., and Microsoft Inc. 


Invited talks: 

Gerrit Noordzij (Tuil, The Netherlands): The shape of the stroke: the cultural paradigm 
Andre Giirtler (Schule fur Gestaltung): The design and adaptation of typeforms for the grayscale screen 
Wang Xuan (Peking U.): The state of digital typography in China 
Matthew Carter (Bitstream Inc.): Theories of letterform construction 
Papers to be presented: 

J. Gonczarowski (Typographies Ltd.): A fast approach to autotracing (with parametric cubics) 

R. Southall (Royal College of Art): Character description techniques in type manufacture 
E. van Blokland, J. van Rossum (The Hague): Different approaches to lively outlines 
A. Naiman (U. Rochester): CRT spatial non-linearities and luminance linearization 

G. Avrahami, V. Pratt (Stanford U.): Sub-pixel edge detection in character digitization 
J. Farrell (Hewlett-Packard): Grayscale/resolution tradeoffs in image quality 

Y. Zheng (U. Montana): Subdivision-remainder method for converting spatial resolution to intensity resolution 
T. Mitsa, R. Ulichney, K.J. Parker (U. Rochester, DEC): The construction and evaluation of halftone patterns 
with manipulated power spectra 
I. Amidror (EPFL): The moire phenomenon in color separation 

C. Cook (Phoenix Technologies): Color digital halftoning using multi-cluster halftone dots 

I. J. Tamari (Darmstadt, Germany): Decipherability, legibility and readability of modern Hebrew typefaces 

C. Rosenberg (Hewlett-Packard): A low-complexity method for compressing Kanji font bitmaps 

H. Abe, Y. Yamamoto, Y. Ohno (Keio U.): High quality halftone Kanji font generation 

using automatic stroke displacement 

D. Yunmei, L. Kaide (Academica Sinica): Parametric graphical approach to Chinese font design 

J. Fan (Academica Sinica): Towards intelligent Chinese character design 

M. Corthout, E.-J. Pol (Philips Research): Supporting outline font rendering in dedicated silicon: 
the PHAROS chip 

R.D. Hersch, C. Betrisey (EPFL): Advanced grid constraints: performances and limitations 
P.A. MacKay (U. Washington): Looking at the pixels 

Tutorials: 

Kris Holmes, Hans Eduard Meier (Bigelow & Holmes, Menlo Park; Horgen, Switzerland): An 
introduction to the design of letters: a tutorial for non-designers 
Jacobo Valdes (Sun Microsystems): Current digital type technology: a tutorial for non-technical typographers 

The tutorials will be held non-concurrently on October 14, the day before the conference. 

The deadline for advance registration is September 15, 1991. 

To receive electronic or paper mail about the conference, please contact: 

RIDT 91 

Department of Mathematics and Computer Science telephone: (617) 287-6466 
Harbor Campus fax: (617) 265-7173 

UMass/Boston email: ridt91-requegt@cs.umb.edu 

Boston, MA 02125-3393 
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JC An nouncements _ 

Company, Model, Function Comments r.S. No. 


Amp Inc. 
AmpflatLGA 
Socket assembly 


Anacad Computer 
Systems 
Eldo4.0 
Simulator 


Analog Devices 
SSM-2018 
Voltage-controlled 
amplifier 


Eesoflnc. 
Emsim3.0 
Circuit simulator/ 
analyzer 


Accommodates LGA packages with up to 484 positions on a 0.051-in. centerline grid with a 120 

profile of less than 0.357 in. above the PCB. Contact array is 0.009 in. high when fully com¬ 
pressed, providing less than 10-picosecond delay and 200° C-per-watt thermal resistance per 
contact or 0.5° C -per-watt total. LG As serve applications requiring high density and high¬ 
speed signal transmission between two parallel surfaces. 

Simulator includes Eldo-Fas, for analog modeling and simulating of PLLs, VCOs, and DC 121 

motors; Eldo-XL, for timing simulations in parallel with analog simulations; Eldo-Opt, for 
cell optimization and transistor dimensioning; Eldo DSP, for digital signal processing; Eldo- 
UDM, for user definable models; and Others, for performing Monte Carlo and sensitivity 
analysis and transfer functions in S&Z domains. 

High-performance monolithic VCA, designed for electronic volume control systems, mix 122 

consoles, and other noise-reduction systems where remote, automatic, or computer control 
of gain and attenuation is desirable. Operates in either the voltage or current domain. In¬ 
cludes lOV/ps slew rate, 14-nV/VHz input voltage noise, 12-MHz gain bandwidth product, 
and -1 mV (untrimmed) control feedthrough. Comes in 16-pin plastic DIPs or SOICs. Cost 
(100s): $3.25. 

Component provides electromagnetic simulation of entire planar microwave circuits. Ap- 123 

propriate in design and analysis of high-frequency communications circuits where inter¬ 
element coupling and circuit compaction effects degrade circuit response and cannot be ana¬ 
lyzed using popular equivalent circuit-simulation technology. Available now on the Sun 4 
and Sparcstation, later this year on HP and IBM computers. Cost: from $19,500. 


Elite Microelectronics A 40-MHz submicron logic chip set, Screaming Eagle supports Advanced Devices’ Am386 124 

Screaming Eagle microprocessor. Features integrated cache controller, offers 9.8-MIPS performance with an 

PC chip set upgrade path, and uses 0.8-micron CMOS technology. Consists of a 184-pin PQFP and a 160- 

pin PQFP device, provides core logic functions, CPU bus control, on-chip page-interleave 
DRAM control, and data conversion between buses. Cost (1,000s): $95. 


Hampshire Instruments 
Series 3500 
Stepper System 
X-ray lithography 
system 


Stepper System uses X rays to print IC designs no wider than 0.35 microns to allow more ca¬ 
pabilities on a chip. Can be used as foundation for a process line for next-generation manu¬ 
facturing or can be mixed into existing optical lithography, using same photoresist process 
to improve capabilities and increase yields of current designs. System has high resolution for 
clear device images and precise design depths, as well as immunity to organic particulates. 
Same size as optical system and fits into standard cleanroom. Delivery: 12 months after re¬ 
ceipt of order. Cost: approximately $4,000,000. 


125 


Linear Technology 
LT1223 

Current feedback 
amplifier 


Using thin-film resistors and wafer-level trims, the LT1223 has 3- m i ll ivolt maximum offset 126 

voltage and 3-microampere maximum input bias currents. Company says amplifier is 10 
times more accurate than earlier devices. Guarantees 50 milliamperes of output drive and is 
specified for operation on ±4.5 V to +18V supplies. Available in eight-pin plastic dual in-line 
or ceramic packages and in eight-pin small-outline packages. Military, industrial, and com¬ 
mercial temperature-range Versions. Cost (100s): $2.85. 


LSI Logic Corp. Enhanced read/write buffer, available in 33- and 40-MHz versions, provides a 32-bit interface 127 

LR3230 between the Mips RISC CPU/cache subsystem and main memory. Its nine-word buffer mini- 

Buffer chip mizes likelihood of processor stalls at 40 MHz. Fabricated using LSI Logic’s 1.0-micron 

drawn (0.7 effective) channel-length HCMOS Compacted Array technology. Housed in a 
223-pin ceramic PGA. Cost(l ,000s): 33 MHz, $175; 40 MHz, $228. 


Newer Technology Modules can be upgraded at the factory to a full 16 Mbytes. Allows Mac users to start with less 128 

8-Mbyte SIMM expensive unit and upgrade when necessary. Available in 64-pin Macintosh Ilfx format. Uses 

70-ns RAM and 7-ns logic devices, compatible with fast Mac Ilfx. Applications include 
graphic imaging, desktop publishing, color prepress, CAD/CAM, database, networking en¬ 
vironments, and other memory-intensive applications. 


Philips Semiconductors Continuous-calibration D AC for portable compact disc and other digital audio equipment, 129 

TDA1545 with total harmonic distortion, including noise, at full signal of-81 dB (0.0089%), fits in an 

D Ac eight-pin DIL or SO package. Has power dissipation of 6 mW at 3 V, rising to 15 mW at 5V. 
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Microsystem Announcements 

Company, Model, Function_Comments_R-S. No. 


Cache Computers Inc. 

486SX/BAT 

Motherboard 


Deskstation 

Technology 

AT29K 

Motherboards 


Hauppauge Computer 

Works 

386-N 

Motherboards 


Motorola 

MVME167 

Single-board computer 


National Instruments 
AFFA, NB-DSP2301, 
NB-2150, DSP memory 
expansion, NB-A2150 
Analyzer and boards 


Pioneer Computer 
Vantage 386 Cache 
Motherboards 


Combines i486SX CPU with up to 256 Kbytes of external cache and up to 32 Mbytes of on- 135 

board RAM. Includes built-in IDE, parallel and serial ports. Offers 8 Kbytes of internal 
cache. Socketed for Weitek coprocessor, with socket for i487SX coprocessor expected by 
date of publication. Board comes with AMI, Phoenix, or Cache B AT486 BIOS. Evaluation 
units available immediately, volume shipping scheduled for third quarter 1991. Cost: $850. 

Include 2 Mbytes of video DRAM and a ROM-resident monitor (source code for monitor 136 

available to users at no charge). Model 162 with a 16-MHz AM29000 provides 9-MIPS and 
15,000-Dhrystone operation. Model 202, a 20-MHz AM29000, provides 11 MIPS and 
18,000 Dhrystones. Model 252, a25-MHz AM29000, provides 14 MIPS and23,500 Dhrys- 
tones. Cost: Model 162, $2,495; Model 202, $2,995; Model252, $3,495. 

At 25 and 33 MHz, boards feature i386DX CPU; eight 16-bit expansion slots; 1 to 32 Mbytes 137 

SIMM memory; static cache RAM from 0 to 256 Kbytes; sockets for i387, Weitek 3167, or 
Cyrix EMC87 coprocessors; and built-in serial, parallel, mouse, IDE, and floppy interfaces. 
Operates with DOS 4.01, Netware 386, Unix (SCO, Interactive, AT&T), Xenix, Windows 
3.01, OS/21.2EE, and hardware add-ons. Cost: from $1,329. (Series also includes a 20-MHz 
i386SX board, from $995.) 

Company claims the MVME167 achieves 20 MIPS at 25 MHz (Dhrystone 1.1) using the 138 

68040 CISC. Price/performance ratio below $200/MIPS. Key features include VME D64 
protocol, CMOS electronics, SCSI interface, Ethernet interface, serial and parallel ports, 
and real-time interrupt handlers. Samples available in July, volume shipments begin in 
November. Cost: $3,995. 

Audio Frequency Fourier Analyzer (AFFA) combines National’s NB-DSP2300 board, NB- 139 
A2100 input board, and Labview 2 graphical software. The NB-DSP2301 is an analysis accel¬ 
erator and DSP board designed to speed up numerically intensive data processing and analy¬ 
sis. The NB-A2150 four-channel audio frequency analog input board comes in three 
versions. The DSP memory expansion board provides 320 Kwords of zero-wait-state memo¬ 
ry for DSP programs and data. Costs: AFFA, from $7,495; NB-DSP2301, $3,495; DSP memo¬ 
ry expansion board, $1,995; NB-A2150, $1,995. 

Boards come with either AMD’s AM386-40 CPU or the i386-33 CPU, 64 Kbytes cache mem- 140 
ory (upgradable to 128 Kbytes), and up to 32 Mbytes of on-board memory. Support 80387 
math coprocessor. Boards use ASIC chip-set design, have mini-AT footprint and eight 
16-bit AT-compatible slots. Cost: 33 MHz, $630; 40 MHz, $855. 


Sharp Digital Single-board real-time PC image-processing system occupies one 16-bit AT slot. Functions 141 

GPB-1 at speeds up to 40 ns per pixel and accepts synchronous or asynchronous input in standard 

Image-processing board RS-170 video format. Provides 1/0,12 planes of 512 x 512 X 8-bit image memory, external in¬ 
terfaces, and a separate connector for directly accessing the board’s image data buses. Cost 
(100s): $4,800. 


Signal Processing System board provides 20-MIPS and 60-Mflops performance with expandable on-board 142 

ADSP21020 memory, PC interface, DSP-link parallel expansion port, and analog I/O daughterboard 

System and processor equipped with two channels. Each channel includes A/D and D/A converters operating at 

boards 200 kHz. Cost: system board, from $5,995; processor board, $4,995. 


Step Engineering Analyzer with 1 -Mword-deep and 256-bit-wide trace, preconfigured for AT-class 286/386/ 143 

Step-40 SDT 486 machines that have a minimum 2 Mbytes of memory. Design tools include 16-level real- 

Logic state analyzer time trigger mechanisms, breakpoint facilities to support 32-bit (and wider) architectures, 

ancillary clock controls, time tagging, and real-time histogramming facility. Reconfigurable 
to any mnemonic set for display purposes. Cost: from $25,000. 

Western Datacom DES encryption modem with group 3 fax support features speeds up to 19,200 bps. Compati- 144 

Mesa432i ble with IBM PC XT/AT bus and most popular communications packages. Call-back securi- 

Security modem ty, MNP error correction and data compression, remote configuration and diagnostics, and 

testing and status-reporting capabilities. Certifiedfor class2 data transmission. Cost: $1,095. 

432i line backer: $895. 
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The 17-th International Conference on Very Large Data Bases 

General Chair: Felix Saltor, Spain; Conference Chairs: David K. Hsiao, USA, & Georges Gardarin, France; 


Panels Chair: Alfonso F. Cardenas (USA) 
Tutorials Chair: Antoni Olive (Spain) 

sponsored by The VLDB Endowment 
(YLDBE), an IFIP affiliate 

supported by 


A AshtonTate® 



= =-= == Almaden Research Center 

C3EH2 

0SYBASE' 

Tandem Computers 

ATeradata 

UNISYS Productivity Software Group 

II 

in cooperation with 

For a free copy of the Call-for-Attendance brochure, write to Prof. 
David K. Hsiao, Computer Science Department, Naval Postgraduate 
School, Monterey, CA 93943, U.S.A. or to Victor Obach, DIFINSA, 
Av. Republica Argentina, 63, Ent. 4a, E - 08023 Barcelona, Spain. 


VLDB ‘91 PROGRAM 


===== Tuesday, 3 September 1991 ==== 
RECEPTION & OPENING SESSION 


EXPLOITING DATA SEMANTICS, Chair: P. Apers (Netherlands) 
Semantic Modelling of Object-Oriented Databases 
M. Bouzeghoub and E. Metais (France) 

Integrating Implicit Answers with Object-Oriented Queries 
H.T. Siegelmann and B.R. Badrinath (USA) 

A Methodology for the Design and Transformation of Conceptual 
Schemas, C.F. Eick (Italy) 

CONCURRENCY CONTROL & PERFORMANCE 
Chair: G. Schlageter (Germany) 

Experimental Evaluation of Real-Time Optimistic Concurrency 
Control Schemes 

J. Huang, J.A. Stankovic, K. Ramamritham, and D. Towsley (USA) 
Adaptive Load Control in Transaction Processing Systems 
H-U. Heiss and R. Wagner (Germany) 

A Performance Evaluation of Multi-Level Transaction Manage¬ 
ment, C. Hasse and G. Weikum (Switzerland) 

TUTORIAL: Conceptual Modeling Using an Extended E-R Model 
Ramez Elmasri (USA) 

NEW APPLICATIONS, Chair: S. Christodoulakis (Canada/Greece) 
Semantic Queries with Pictures: the VIMSYS Model 
A. Gupta, T.E. Weymouth, and R. Jain (USA) 

Optimization Strategies for Spatial Query Processing 
W.G. Aref and H. Samet (USA) 

Efficiency of Nested Relational Document Database Systems 
J. Zobel, J.A. Thom, and R. Sacks-Davis (Australia) 

TRANSACTIONS & INTEGRITY, Chain C. Mohan (USA) 

A Formalism for Extended Transaction Models 
P.K. Chrysanthis and K. Ramamritham (USA) 

A Transactional Model for Long-Running Activities 

U. Dayal, M. Hsu, and R. Ladin (USA) 

Safe Referential Integrity Structures in Relational Databases 

V. M. Markowitz (USA) 

========== Wednesday, 4 September 1991 ========= 

SCHEMA INTEGRATION & EVOLUTION 
Chair: N. Roussopoulos (USA) 

A Metadata Approach to Resolving Semantic Conflicts 
M. Siegel and S.E. Madnick (USA) 

Solving Domain Mismatch and Schema Mismatch Problems with an 
Object-Oriented Database Programming Language, W. Kent (USA) 
Management of Schema Evolution in Data Bases 
J. Andany, M. Leonard, and C. Palisser (Switzerland, France) 

INTEGRITY & COHERENCY CONTROL 
Chair: P. Dadam (Germany) 

Using Write Protected Data Structures To Improve Software Fault 
Tolerance in Highly Available Database Management Systems 
M. Sullivan and M. Stonebraker (USA) 

Adaptive Locking Strategies in a Multi-Node Shared Data Model 
Environment, A.M. Joshi (USA) 

Recovery and Coherencey-Control Protocols for Fast Intersystem 
Page Transfer and Fine-Granularity Locking in a Shared Disks 
Transaction Environment, C. Mohan and I. Narang (USA) 
















(VLDB ‘91), Barcelona, Catalonia, Spain, Sept. 3rd - 6th, 1991 

Prog. Chairs: Guy Lohman, USA, & Amilcar Semadas, Portugal; VLDBE Rep: Peter Lockemann, Germany 


TUTORIAL: Active Database Systems 
U. Dayal (USA) and K. Dittrich (Switzerland) 

THEORY, Chair: M. Casanova (Brazel) 

Algebraic Properties of Bag Data Types, J. Albert (USA) 

The Power of Methods with Parallel Semantics 
K. Denninghoff and V. Vianu (USA) 

Dynamic Constraints and Object Migration, J. Su (USA) 

IMPROVING PERFORMANCE, Chair: J.E.B. Moss (USA) 

Object Placement in Parallel Hypermedia Systems 
S. Ghandeharizadeh, L. Ramos, Z. Asad, and W. Qureshi (USA) 
Fido: A Cache that Learns to Fetch 
M. Palmer and S.B. Zdonik (USA) 

Predictive Load Control for Flexible Buffer Allocation 
C. Faloutsos, R. Ng, and T. Seffis (USA) 

RULE IMPLEMENTATION & PERFORMANCE 
Chair: H.V. Jagadish (USA) 

Implementing Set-Oriented Production Rules as an Extension to 
Staiburst, J. Widom, RJ. Cochrane, and B.G. Lindsay (USA) 
Effects of Database Size on Rule System Performance: Five Case 
Studies, D.A. Brant, T. Grose, B. Lofaso, and D.P. Miranker (USA) 
Data Management for Large Rule Systems 
A. Segev and J.L. Zhao (USA) 

PANEL: Data and Knowledge Bases for Genome Mapping: What Lies 
Ahead? Chair: N. Kamel (USA) 

TUTORIAL: Distributed Database Management: Current State-of- 
the-Art, Unsolved Problems, and New Issues, M.T. Ozsu (Canada) 


======= Thursday, 5 September 1991 ===== 

ACTIVE OBJECT-ORIENTED DATABASES 
Chair: U. Dayal (USA) 

Rule Management in Object-Oriented Databases: A Uniform 
Approach, O. Diaz, N. Paton, and P. Gray (Spain) 

Ode as an Active Database: Constraints and Triggers 
N.H. Gehani and H.V. Jagadish (USA) 

A Model for Active Object-Oriented Database 
C. Beeri and T. Milo (Israel) 

QUERY PROCESSING, Chair: J.C. Freytag (Germany) 

Kaleidoscope Data Model for an English-like Query Language 
S.K. Cha and G. Wiedeihold (USA) 

Extending the Search Strategy in a Query Optimizer 
R. Lanzelotte and P. Valduriez (France) 

Performance Analysis of a Load Balancing Relational Hash-Join 
Algorithm for a Shared Memory Multiprocessor 
E. Omiecinski (USA) 

TUTORIAL: Cooperative Access to Data and Knowledge Bases 
R. Demolombe (France) 


PHYSICAL DATABASE DESIGN, Chair: H. Lu (Singapore) 

An Iterative Method for Distributed Database Design 
R. Blankinship, A. Hevner, and S.B. Yao (USA) 

Using Feature Set Compromise to Automate Physical Database 
Design, S. Rozen and D. Shasha (USA) 

Optimizing Random Retrievals from CLV Format Optical Disks 
D. Ford and S. Christodoulakis (Canada) 


TEMPORAL DATABASES, Chair: S. Chakravarthy (USA) 
Temporal Logic & Historical Databses 
D. Gabbay and P. McBrien (UK) 

A Temporal Knowledge Representation Model OSAM*/T and its 
Query Language OQL/T, S.Y.W. Su and H-H.M. Chen (USA) 

An Evaluation of Non-Equijoin Algorithms 

D.J. DeWitt, J.E. Naughton, and D.A. Schneider (USA) 

PANEL: Database Technologies for the 90’s and Beyond 
Chair: M. Kamel (USA) 

TECHNIQUES FOR ACTIVE DATABASES 
Chair: C. Beeri (Israel) 

Language Constructs for Programming Active Databases 
R. Hull and D. Jacobs (USA) 

Alert: an Architecture for Transforming a Passive DBMS into an 
Active DBMS 

U. Schreier, H. Pirahesh, R. Agrawal, and C. Mohan (USA) 

On Maintaining Priorities in a Production Rule System 

R. Agrawal, R.J. Cochrane, and B.G. Lindsay (USA) 

TUTORIAL: Federated Database Systems for Managing Distributed, 
Heterogeneous, and Autonomous Databases 
A.P. Sheth (USA) 

DEDUCTIVE DATABASES, Chair: G. Gardarin (France) 

A Functional Programming Approach to Deductive Databases 
A. Poulovassilis and C. Small (UK) 

Aggregation and Relevance in Deductive Databases 

S. Sudarshan and R. Ramakrishnan (USA) 

Integrity Constraints Checking in Deductive Databases 
A. Olive (Spain) 

PARALLEL JOIN METHODS 
Chair: D. DeWitt (USA) 

Handling Data Skew in Multicomputer Database Systems Using 
Partition Tuning, K.A. Hua and C. Lee (USA, Taiwan) 

A Taxonomy and Performance Model of Data Skew Effects in Par¬ 
allel Joins, C.B. Walton, A.G. Dale, and R.M. Jenevein (USA) 
Optimization of Muti-Way Join Queries for Parallel Execution 
H. Lu, M-C. Shan, and K-L. Tan (Singapore, USA) 


======== Friday, 6 September 1991 ======== 

PANEL: Interoperability in Multi-Databases: Semantic and System 
Issue 

Chair: Yuri Breitbart (USA) 

BEST PAPER SESSION 

Chair: A. Semadas (Portugal) and G. Lohman (USA) 

A Relationship Mechanism for a Strongly Typed Object-Oriented 
Database Programming Language 
A. Albano, G. Ghelli, and R. Orsini (Italy) 

Deriving Production Rules for Incremental View Maintenance 
S. Ceri and J. Widom (Italy, USA) 

TUTORIAL: Logic Programming Environments for Large Knowl¬ 
edge Bases: A Practical Perspective 
J. Bocca (Germany) 


CLOSING SESSION 













UPDATE 


ContriDunons to Update are welcome. Send news of public policy or professional issues and of industrial or university research to 
Bob Carlson, 10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1264 


Faster. . . 

Caltech dedicates world’s most powerful supercomputer 

Ware Myers 
Contributing Editor 


George E. Brown, Jr., chairman of 
the US House Committee on Science, 
Space, and Technology, cut the ribbon 
around the Intel Touchstone Delta 
System in ceremonies at the Califor¬ 
nia Institute of Technology May 31. 
Termed “the world’s most powerful 
computer” by Thomas E. Everhart, 
Caltech president, the message-pass¬ 
ing concurrent computer will be used 
not only by Caltech but also, through 
high-speed communication links, by 
scientists working at other institutions 
in the nationwide 14-member Concur¬ 
rent Supercomputing Consortium (see 
Computer, January 1991, p. 122). 

The “most powerful” claim is based 
on Delta’s 8.6-Gflops performance on 
the massively parallel Linpack bench¬ 
mark. The previous record, 5.2 
Gflops, was set only last March by 
Thinking Machines’ CM-2. The Delta 
benchmark was performed under the 
direction of Jack Dongarra of the 


University of Tennessee, author of the 
Linpack benchmark. 

“The Delta benchmark was a 
straightforward implementation of 
work done on an Intel iPSC/860 sys¬ 
tem,” Dongarra said. “We used Intel’s 
standard compilers combined with the 
Intel-supplied BLAS (basic linear al¬ 
gebra subroutines) mathematical 
function library.” 

“This new Linpack result is directly 
relevant to a large number of prob¬ 
lems in technical computing,” added 
Ray Asbury, manager of technical 
marketing at Intel Supercomputers. 
“Most of these problems involve the 
solution of large systems of equations. 
This is exactly what Linpack does. 

The Delta results were achieved on 
problems of substantially smaller size 
than previous record Linpack results. 
This means that Delta will give excel¬ 
lent performance on a wider range of 
problems.” 


Some idea of the sheer magnitude 
of the world’s most powerful comput¬ 
er can be gained if we imagine it being 
divided among the 2,500 students, 
professors, and research staff mem¬ 
bers at Caltech. Each would gain ac¬ 
cess to a quarter of a million transis¬ 
tors’ worth of processor power, 3.4 
Mbytes of memory, and 36 Mbytes of 
on-line disk storage. (For key specifi¬ 
cations, see the sidebar on next page.) 


And faster... 

As we go to press, Thinking Ma¬ 
chines Inc. has again claimed the 
“most powerful machine" title. On 
June 4 the company introduced the 
CM-200 massively parallel super¬ 
computer, said to be almost twice 
as fast as Thinking Machines’ pre¬ 
vious record holder. The new ma¬ 
chine benchmarks at 9.03 Gflops, a 
little ahead of the Caltech ma¬ 
chine’s 8.6 Gflops. 

And faster.... The following day, 
June 5, Intel announced the i860 XP 
processor chip, which is about twice 
as powerful as the i860 in the Intel 
Touchstone Delta System. Gordon 
Moore, speaking the week before at 
the Caltech dedication, had foreshad¬ 
owed this chip, saying: “Very shortly, 
the next generation, each [processor] 
containing 2.5 million transistors, will 
be announced, allowing higher perfor¬ 
mance parallel machines to be built.” 

Intel has said all along that there 
will be one more prototype in the 
Touchstone program, the Sigma. 
“Sigma will scale to at least 2,048 
processors and provide aggregate 
performance exceeding 150 Gflops 
and 100,000 MIPS,” Moore said. 

— W. M. 



The transparent front panel of the Intel Touchstone Delta System at the Cali¬ 
fornia Institute of Technology lets the parallel programmer follow in a general 
way the flow of operations and detect program bottlenecks. 
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Inside the world’s most 
powerful computer 

528 i860 numeric nodes, 16 
Mbytes memory each 
82 Intel 386 input/output nodes: 
Disk: 64 

Tape: 10 

Ethernet: 2 
Service: 6 

Total memory: 8.4 Gbytes 
On-line disk capacity: 90 Gbytes 
Peak speed: 31.7 Gflops (64-bit); 
42.2 Gflops (32-bit); 17,000 MIPS 
Power: less than 25 kilowatts, air 
cooled 


Viewing program performance live. 

One of the problems programmers of 
massively parallel systems face is visu¬ 
alizing what those 528 numeric pro¬ 
cessors are doing. Delta’s 16 x 5-foot 
black-Plexiglas front panel, shown in 
the accompanying photo, constitutes 
one giant display of what they are do¬ 
ing. Behind the Plexiglas, each proces¬ 
sor is represented by a set of three 
colored light-emitting diodes indicat¬ 
ing the processor’s current mode. 

Each processor is connected to the 
four adjacent processors (in a two-di¬ 
mensional mesh) by two longer LEDs, 
one green and one yellow. The colors 
indicate the direction in which a mes¬ 
sage is passing. 

When the processors are in operat¬ 
ing mode and the communications 
paths are lit, the program is using all 
of the system’s resources. If a section 
of the display goes black, the corre¬ 
sponding processors are probably 
waiting for some other operation to 
give them input. If this wait is what 
the programmer had in mind, fine. 

But if one part of the program unex¬ 
pectedly got ahead of another part, 
then the programmer may be able to 
speed up the program by balancing 
the load better. 

The program operating during the 
demonstration lit up the entire display 
for several seconds. Then part of the 
display went largely dark. Next, a sin¬ 
gle column of processors lit up for 
milliseconds as the program began to 
build a colored visualization on a 
cathode ray tube. Successive columns 
lit up for each line of the visualization. 
Most of the processors and communi¬ 
cation links were idle until the visual¬ 
ization was complete. Then all the 
processors swung into action again to 
compute the next frame. 


“To compute where no one has 
computed before.” Thus spoke Ste¬ 
phen Squires, director of DARPA’s 
Computing Systems Technology Of¬ 
fice, summing up in an apt phrase 
what many of the dedication speakers 
addressed. For instance, when intro¬ 
ducing Edward Stone, Jet Propulsion 
Laboratory director, Congressman 
Brown commented, tongue in cheek: 
“The last three days in Washington 
have been the hottest days in history. 

I have talked to a number of people 
back there who feel that global warm¬ 
ing is a reality. They want the first 
‘grand challenge’ to be doing some¬ 
thing about it.” 

“The problem is one of predicting 
what will happen in such a complex 
system affected by a multitude of pa¬ 
rameters,” Stone responded. “A real¬ 
istic interactive climatic model re¬ 
quires massive amounts of data.. . . 
The complexity of such models has 
greatly exceeded our computing capa¬ 
bility. With the Delta machine we can 
significantly improve these simula¬ 
tions, eventually leading to accurate 
predictions.” 


The 1990 median income of US 
members of IEEE who are employed 
full-time in their primary areas of 
technical competence is $58,000. In 
addition, according to the salary sur¬ 
vey recently published by IEEE Unit¬ 
ed States Activities, median starting 
salaries in 1991 for electrical engi¬ 
neers range from $32,000 in govern¬ 
ment to $35,500 in companies employ¬ 
ing 10,000 or more. 

While the purchasing power of elec¬ 
trical engineers increased by 1.8 per¬ 
cent between the 1989 and 1991 sur¬ 
veys, in the 1990 calendar year almost 
6 percent of the respondents reported 
“some period of involuntary unem¬ 
ployment” averaging 17 weeks. 


Checker- and chess-playing comput¬ 
ers are nothing new, but a robot that 
selects and then makes its moves with 
a 4-inch yellow foam nose has a few 
extra tricks in its repertoire. 

“Our ultimate goal isn’t to build 
checker-playing robots,” said Thomas 
LeBlanc, associate professor of com¬ 
puter science at the University of 
Rochester, “but rather computer sys¬ 
tems that do different kinds of tasks 
simultaneously. It would be extremely 
difficult to integrate these abilities 


Climatic modeling is only one of the 
“grand challenges” awaiting the 
Touchstone Delta. “We will be solv¬ 
ing problems that could not be solved 
before,” Everhart said. 

Or, in Brown’s words: “We should 
be prepared to be startled by totally 
unimagined applications.” 

“Delta allows important problems 
to be addressed that were incalculably 
difficult previously,” noted Gordon 
Moore, chairman of Intel. “It is by no 
means the end. Even as we are dedi¬ 
cating the world’s fastest computer, 
we are already close to the birth of 
the next generation. 

“The fastest machine can hope to 
hold that title only for a short period,” 
he continued. “We can look forward 
to several years of very rapid evolu¬ 
tion in this technology. Performance 
improves almost linearly with the 
number of processors added. This 
scalable architecture opens the path 
to additional orders-of-magnitude in¬ 
creases in speed and performance. 
Teraflops, the Holy Grail of comput¬ 
ing, now appears to be within reach.” 


The publication reports 1990 medi¬ 
an income in 10 major areas of techni¬ 
cal competence ranging from a low of 
$54,000 in systems and control to a 
high of $66,800 in engineering and hu¬ 
man environment. In the computer 
area, with the largest number of re¬ 
spondents, medians were $55,900 for 
software and $56,000 for hardware. 

The 128-page 1991 IEEE US Mem¬ 
bership Salary Survey is available to 
members for $74.95 and nonmembers 
for $99.95. Inquiries specifying Cata¬ 
log No. UH0185-9 should be directed 
to the IEEE Service Center, 445 Hoes 
Ln., PO Box 1331, Piscataway, NJ 
08855-1331. 


without being able to use different 
models of parallelism.” 

A complex problem such as en¬ 
abling a robot to play checkers at a 
brisk and responsive pace often calls 
for parallel computation. In the past, 
a single operating system could man¬ 
age only one parallel programming 
approach. But the new Rochester 
technology allows programmers to use 
different models to tackle various as¬ 
pects of a problem. 

By integrating several different 


Median income placed at $58,000 for EEs 


Robot plans — and makes — own checker moves 


July 1991 
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Board of Governors approves slate of candidates 
for fall election 


styles of parallel computing in one op¬ 
erating system, University of Roches¬ 
ter scientists reduced the time needed 
to build a system with multiple capa¬ 
bilities, because programmers didn’t 
have to translate different languages 
into a single language. 

“Different languages do different 
things,” said Michael Scott, assistant pro¬ 
fessor of computer science. “This technol¬ 
ogy allows you to glue together pieces of 
programs easily that once upon a time 
couldn’t be run together.” 

The robot uses four different paral¬ 
lel programming models: one for vi¬ 
sion, one for moving the checkers, one 
for planning the strategy, and another 
that runs the “voice box.” Scott and 
others developed the strategy portion 
at the University of Wisconsin in the 
early 1980s, and it was simply inserted 
into the larger checkers program. 

The robot can also detect illegal moves, 
and with its voice synthesizer exposes 
would-be cheaters to all within earshot. 

Better electrical flow 
reported in prototype 
superconducting device 

Bellcore researchers have demon¬ 
strated that it is possible to layer ex¬ 
tremely thin films of superconducting 
and nonsuperconducting materials, 
aligning individual atoms in a precise 
and predictable way so that critical 
electrical connections between the 
layers can be improved. 

Using a modified version of the 
Bellcore-developed pulsed excimer la¬ 
ser deposition process, the scientists 
grew prototype devices made up of 
atom-thin layers of superconducting 
yttrium-barium-copper-oxide and 
nonsuperconducting praseodymium- 
barium-copper-oxide. Each layer of 
these compounds contains “planes” of 
linked copper and oxygen atoms. 

These planes carry most of the electri¬ 
cal currents in, and through, the su¬ 
perconducting and nonsuperconduct¬ 
ing materials. 

“The key is being able to make the 
copper-oxide planes (along with the 
rest of the molecular compounds) 
within each layer stand up vertically 
and line up end to end,” said research¬ 
er Arun Inam. “This alignment — 
making the planes perpendicular to 
the surface of the chip — allows for 
the best flow of electrical ‘supercur¬ 
rents’ through the various layers.” 

The technique has the potential to 
make Josephson junctions more control¬ 
lable and more easily reproduced, point¬ 
ing the way to mass-produced devices. 


The IEEE Computer Society Board 
of Governors has approved the slate of 
candidates for president-elect, first vice 
president, second vice president, and 
seven board posts that will be filled by 
membership vote this fall. The board 
took action on the slate when it met in 
Austin, Texas, May 17, during ICSE 
13, the 13th International Conference 
on Software Engineering. 

Those elected, including the seven 
candidates receiving the greatest num¬ 
ber of votes among the 11 Board of 
Governors nominees, will begin their 
terms January 1,1992. 

The candidates are as follows: 

1992 president-elect (1993 president, 
1994 past president) 

(One elected) 

James H. Aylor 
Laurel V. Kaleda 

1992 first vice president 

(One elected for one year) 

Barry W. Johnson 
Yale N. Patt 

1992 second vice president 

(One elected for one year) 

Joseph Boykin 
Raymond E. Miller 

1992-94 Board of Governors 

(Seven elected for three years) 

Mario R. Barbacci 
Luis-Felipe Cabrera 
Sumit DasGupta 
Wolfgang K. Giloi 
John R. Gurd 
Michel Israel 
Guylaine M. Pollock 
John P. Riganati 
Vincent Y. Shen 
Ronald D. Williams 
Thomas W. Williams 

Additional nominees can be includ¬ 
ed on the ballot by membership peti¬ 
tion (see Computer, February 1991, p. 
76, for a complete list of Computer 
Society requirements for petition can¬ 
didates). 

Petition candidates must submit 


their petition signatures (1,000 voting 
members for officer nominees and 250 
voting members for Board of Gover¬ 
nors nominees) and their biographical 
data, photographs, and position state¬ 
ments to the Computer Society secre¬ 
tary at the following address on or be¬ 
fore July 31,1991: 

James H. Aylor 
University of Virginia 
Thornton Hall/Electrical Engineer¬ 
ing 

Charlottesville, VA 22903 

Candidates’ statements and bio¬ 
graphical data will be published in the 
September 1991 issue of Computer 
and will be included in the August 16, 
1991, IEEE ballot mailing. Length 
limitations for these materials are as 
follows: 

Candidates’ statements 
President-elect — 350 words 
Vice president — 250 words 
Board of Governors — 150 words 

Biographical data 
All candidates — 200 words 

Biographical sketches should cover 
the following topics in the sequence 
listed: 

• Computer Society activities 

• other professional activities 

• current employment, professional 
experience, and accomplishments 

• degree(s) and majors(s) 

• awards and honors 

Nominees should also submit black- 
and-white passport-type photographs 
of themselves for publication along 
with their statements and biographies 
to 

Bob Carlson 
Computer Magazine 
10662 Los Vaqueros Cir. 

PO Box 3014 

Los Alamitos, CA 90720-1264 
Compmail, b.carlson 
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CONFERENCES 

‘Diversity’ the theme at ICSE 13; 
panel covers productivity, management issues 



“Create software engineering, 
please,” said Craig Fields, chief exec¬ 
utive officer of the Microelectronics 
and Computer Technology Corp. con¬ 
sortium, at the conclusion of his Tues¬ 
day, May 14, ICSE 13 opening plena¬ 
ry-session address. Fields also urged 
software developers to “strip away 
the software religion” and adopt a 
more business-oriented approach to 
software creation. 



Tadao Murata of the University of Il¬ 
linois at Chicago acknowledges re¬ 
ceipt of the 1991 IEEE Donald G. 
Fink Prize, presented for the most 
outstanding paper in an IEEE period¬ 
ical. Murata received the prize for 
“Petri Nets: Properties, Analysis, and 
Applications,” published in the April 
1989 Proceedings of the IEEE. IEEE 
President-Elect Merrill W. Buckley, 
Jr., made the presentation at ICSE 13. 


For more extensive coverage of 
ICSE 13, see IEEE Software, July 
1991, page 97. 

Copies of the proceedings are avail¬ 
able from the IEEE Computer Society 
Press, Los Alamitos, California. For 
order information, call (800) CS-books 
or, in California, (714) 821-8380. 


Galen Gruman, IEEE Software 

“Diversity,” not “system design” as 
advertised, proved to be the theme at 
the 13th International Conference on 
Software Engineering. The conference 
program — divided among papers de¬ 
scribing work in progress, panels on 
supporting technologies and overall 
issues, and advocacy-minded keynote 
addresses — exemplified the diversity 
of the disciplines grouped as software 
engineering. This set of multiple, nar¬ 
row focuses drew complaints from 
some attendees, but the sessions on 
overall issues seemed to fuel much 
positive discussion. 

Cosponsored by the IEEE Comput¬ 
er Society and ACM, ICSE 13 was 
held May 12-16 in Austin, Texas. 
About 650 people attended, down 
some 300 from previous years. 

Perhaps the liveliest session was a 
panel covering productivity and man¬ 
agement issues. Bill Curtis of the Soft¬ 
ware Engineering Institute’s process- 
assessment group ran through a litany 
of problems facing software firms: 
wide variance in developers’ produc¬ 
tivity, job interviews that don’t uncov¬ 
er applicants’ skills and shortcomings, 
lack of career planning, inability for 
employees to practice in real projects 
what they learn in company-spon¬ 
sored training classes, the skills lost 
when a project is finished and its team 
split up, and, most fundamental, the 
lack of preparation that managers get 
for management jobs. Software engi¬ 
neers’ deficiencies as managers begin 
in their student days, he said. They 
are neither trained in management 
nor shown how to work on teams. 

Among the solutions Curtis men¬ 
tioned was active mentoring, whereby 
prospective and new managers drawn 
from the engineering staff could be 
shown how to make the transition to 
management and supported in their 
initial efforts. 

Two other problems hinder good 
software management, said Maurice 
Schlumbarger, manager of Cap Gemi¬ 
ni Innovation, a subsidiary of the 
large French software firm Cap Gemi¬ 
ni Societe: First, software managers 
have little training in the areas they 
manage because of the separate man¬ 


agement and technical career paths 
that most companies have. Second, 
most managers don’t like to be chal¬ 
lenged and thus hate to build teams. 

Tom DeMarco, a principal of the 
Atlantic Systems Guild, advocated 
communities within companies for 
employees. “Companies succeed to 
the extent that they allow communi¬ 
ties to survive,” he said. He criticized 
“dreadful uniformity” and urged com¬ 
panies to try different methods: “Each 
project is a pilot project in some 
sense.” DeMarco laid the blame for 
uniformity and lack of communities 
on “fearful management,” hired be¬ 
cause it’s “nonthreatening.” 

What can developers do to encour¬ 
age a feeling of community and moti¬ 
vate their managers to try new ideas? 
“Vote with your feet,” DeMarco said. 
“That’s what capitalism does best: It 
throws out those companies. You can 
do good by helping your company 
succeed. But you can also help by 
helping them fail.” 

“Programmers show better perfor¬ 
mance when they understand their 
personal goals,” said Kouichi Kishida, 
a principal of the Japanese firm Soft¬ 
ware Research Associates. “Maximize 
opportunities for self-study,” he said. 

At a broader level, Europe-based 
consultant Colin Tully identified four 
areas of management failure: corpo¬ 
rate executives’ failure to identify 
software as part of corporate strategy, 
the profession’s failure to form pro¬ 
ductive links with system engineering, 
educators’ failure to adopt engineer¬ 
ing-style courses and adapt business- 
school offerings to tackle information- 
systems management, and nations’ 
failure to treat systems and software 
as part of their economic strategies. 
The basic problem, he said, is “no 
nerve, no vision.” 

DeMarco cautioned the audience 
not to look for magic answers else¬ 
where. “If you’re looking for exam¬ 
ples of bad management, you don’t 
have to look at software. Don’t bring 
in management from elsewhere. 

That’s a disaster,” DeMarco said. In¬ 
stead, build good managers from the 
software profession, he said. 
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CALL 

FOR 

PAPERS 


10th IEEE VLSI TEST SYMPOSIUM 

April 7 - 9, 1992 
Bally's Park Place Casino Hotel 
Atlantic City, NJ 


DESIGN , TEST and APPLICATION: ASICs and SYSTEMS-ON-A-CHIP 

TF.F.F. VLSI Test Symposium presents and explores state-of-the-art test concepts and trends in VLSI 
devices designed as microsystems. This tenth annual symposium will focus on improved approaches 
to overcoming test barriers raised by the ever-increasing complexity and lack of test accessibility of 
today’s ASICs and Systems-on-a-Chip. The symposium will include tutorials (April 6), a plenary 
session, and formal paper sessions with a wide range of VLSI test topics. 


Topics include but are not limited to the following: 


■ Design for Testability ■ Built-In Self-Test 

■ Test Generation and Simulation 

■ CAE/Workstations ■ Design Verification Systems 

■ Mixed Signal Test ■ Ultra High Frequency Test 

■ Test Standards ■ Boundary Scan 

■ Failure Mode Analysis 


■ Fault Modeling and Diagnosis ■ Board Test 

■ System Test ■ Memory Device Test 

■ IDDQTest ■ Neural Network Test 

■ Quality ■ Reliability ■ Concurrent Engineering 

■ Total Quality Management ■ Test Economics 

■ ATE Architecture ■ Test Systems 


The Program Committee invites authors to submit seven copies of a review package consisting of a 
title page and paper. On the title page include: title, author(s), affiliation(s), and an abstract of 50 
words or less. Identify the contact author including a complete mailing address, phone number, fax 
number and e-mail address (if applicable). The submission may be an extended summary or a full 
paper, however the Program Committee will give preference to full paper submissions. Clearly 
describe the nature of the work, explain its significance, highlight novel features, and describe its 
current status. All submissions must be original and unpublished. Authors of selected papers will 
be required to prepare a manuscript for the symposium digest. Outstanding papers will be honored 
with awards. 


■ Abstract and summary due: October 9, 1991 

■ Acceptance notification: November 29, 1991 

■ Camera-ready copy due: January 31, 1992 

■ The committee invites proposals for panels and tutorial topics. 

Submit all papers and proposals to: Dhiraj Pradhan, Program Chairperson 

University of Massachusetts 
Dept, of ECE, Marcus Hall 
Amherst, MA 01003 
Tel: (413) 545-0160 
Fax: (413) 545-4611 


Sponsored by: Test Technology Technical Committee, IEEE Computer Society 
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CALENDAR 


July 1991 


SPAA 91, Third Symp. on Parallel Algo¬ 
rithms and Architecture, July 21-24, Hilton 
Head, S.C. Sponsor: ACM. Contact Tom 
Leighton, MIT Math Dept., 545 Technolo¬ 
gy Sq., Cambridge, MA 02139, phone (617) 
253-3662, e-mail ftl@math.mit.edu. 

1991 Int’l Symp. on Optical Applied Sci¬ 
ence and Eng., July 21-26, San Diego, 

Calif. Sponsor: Int’l Soc. for Optical Eng. 
Contact SPIE, PO Box 10, Bellingham, 

WA 98227-0010, phone (206) 676-3290, fax 
(206) 647-1445. 

SCSC 91,1991 Summer Computer Simula¬ 
tion Conf., July 22-24, Baltimore. Sponsor: 
Soc. for Computer Simulation. Contact 
SCS, PO Box 17900, San Diego, CA 92117- 
7900, phone (619) 277-3888, fax (619) 277- 
3930. 


(SIGGraph 91, July 28-Aug. 2, Las 

vs?' Vegas, Nev. Sponsor: ACM. Contact 
Assoc, for Computing Machinery, 11 W. 
42nd St., New York, NY 10036, phone 
(212) 869-7440. 


August 1991 

Fifth Technical Workshop on New Direc¬ 
tions for Testing, Aug. 1-2, Ottawa, Cana¬ 
da. Cosponsors: Natural Sciences and Eng. 
Research Council of Canada et al. Contact 
Helmut Juergensen, Computer Science 
Dept., Univ. of Western Ontario, London, 
Ont„ Canada N6A 5B7, phone (519) 661- 
3560, fax (519) 661-3515, e-mail helmut@ 


VA1 91, Int’l Symp. on Visual Analysis and 
Interface, Aug. 1-4, Novosibirsk, USSR. 
Contact Victor Sirotin, Computing Center, 
Sib. Div. USSR Academy of Science, 
Pr.Lavrentjeva 6, 630090 Novosibirsk, 
USSR, fax 007-383-2-352-756, 007-383-2- 
355-650, e-mail Jasnet: 02502040300. 


APL 91, Int’l Conf. on APL, Aug. 4-8. 

Palo Alto, Calif. Sponsor: ACM. Contact 
APL 91, 883 Santa Cruz Ave., Suite 30, 
Menlo Park, CA 94025-4658, phone (415) 
326-7781, fax (415) 326-3945. 

Fourth Workshop on Computational 
Learning Theory, Aug. 5-7, Santa Cruz, 
Calif. Contact Jean McKnight, Computer 
and Information Science, Applied Sciences 
Bldg., Santa Cruz, CA 95064, fax (408) 
459-3074, e-mail colt@cis.ucsc.edu. 


fjgjjt In the accompanying Calendar and adjoining Call for Papers, the IEEE 
Computer Society logo identifies the conferences the society is participat¬ 
ing in or sponsoring. Other conferences of interest to our readers — as well as 
their sponsors — are also listed. 

Calendar and Call for Papers notices are published free of charge, in chrono¬ 
logical order, and as space permits. 

When submitting information for inclusion in the Call for Papers section, 
please provide the following: the name of the event, the date(s), the location, the 
sponsor(s), the deadline for submittals, and the phone and fax numbers and — if 
applicable — the electronic address of the person to whom papers should be 
sent. 

For listings in the Calendar section, please provide the following: the event 
name, the date(s), the location, the sponsor(s), and the phone and fax numbers 
and — again, if applicable — electronic address of the person to contact for 
complete information. 

Submitted information should arrive at Computer at least five weeks before 
the month of publication (i.e., for the September 1991 issue, send information 
for receipt by July 22, 1991) to Chuck Governale, Calendar Dept., Computer, 

PO Box 3014, Los Alamitos, CA 90720-1264, fax (714) 821-4010, e-mail 
c.governale@compmail.com. 


for Cryptologic Research et al. Contact 
Burt Kaliski, Crypto 91, RSA Data Securi¬ 
ty, 10 Twin Dolphin Dr., Redwood City, 
CA 94065, phone (415) 595-8782, fax (415) 
595-1873, Internet: burt@rsa.com. 

Third Software Quality Workshop, Aug. 
11-15, Alexandria, N.Y. Sponsor: Rome 
Laboratory. Contact Barbara Radzisz, 
Data and Analysis Center for Software, 

PO Box 120, Utica, NY 13503, phone (315) 
734-3696. 

ICPP 91, 20th Int’l Conf. on Parallel Pro¬ 
cessing, Aug. 12-16, St. Charles, Ill. Spon¬ 
sor: Pennsylvania State Univ. Contact Tse- 
yun Feng, Electrical Eng. East Bldg., 
Pennsylvania State Univ., University Park, 
PA 16802, phone (814) 863-1469, fax (814) 
865-7065, e-mail tfeng@ecl.psu.edu. 

Nat’l Conf. on Computing and Values, 
Aug. 12-16, New Haven, Conn. Sponsor: 
Research Center on Computing and Soci¬ 
ety. Contact Terrell W. Bynum, RCCS, 
Southern Connecticut State Univ., 501 
Crescent St., New Haven, CT 06515, phone 
(203) 397-4423, fax (203) 397-4207, e-mail 
bynum@ctstateu. 

1991 Int’l Conf. on Computer Processing 
of Chinese and Oriental Languages, Aug. 
13-16, Taipei, Taiwan. Cosponsors: Chi¬ 
nese Language Computer Soc. et al. Con¬ 
tact Yaohan Chu, Computer Science 
Dept., Univ. of Maryland, College Park, 
MD 20742, phone (301) 405-2667, fax (301) 
405-6707, e-mail ychu@cs.umd.edu. 

WADS 91, Workshop on Algorithms and 
Data Structures, Aug. 14-16, Ottawa, Can¬ 
ada. Contact WADS 91, School of Com¬ 


puter Science, Carleton Univ., Ottawa, 
Ont., Canada K1S 5B6, phone (613) 788- 
4333, fax (613) 788-4334, e-mail wads@scs. 
carleton.ca. 

PODC 91,10th Symp. on Principles of 
Distributed Computing, Aug. 19-21, Mon¬ 
treal. Sponsor: ACM. Contact Luqi Lo- 
grippo, Computer Science Dept., Univ. of 
Ottawa, Ottawa, Ont., Canada KIN 6N5, 
phone (613) 564-5450, e-mail lmlsl@ 
uottawa. 

Sixth Int’l Conf. CAD/CAM, Robotics, 
and Factories of the Future, Aug. 19-22, 

London. Sponsor: Int’l Soc. for Productivi¬ 
ty Enhancement. Contact H. Bera, Me¬ 
chanical Eng. Dept., South Bank Polytech¬ 
nic, 103 Borough Rd., London SE1 0AA, 
UK, phone 011 (91) 81-928-8989, ext. 2095, 
fax 011 (91)81-261-9115. 

1991 Systems Evaluation and Assessment 
Tech. Workshop, Aug. 20-22, Silver 
Spring, Md. Sponsors: Naval Surface War¬ 
fare Center, Office of Naval Tech. Contact 
Janet Youngblood, NSWC, Code G42, 
10901 New Hampshire Ave., Silver Spring, 
MD 20903-5000, phone (301) 394-3851, fax 
(301) 394-1175, e-mail hwang@nswc-wo. 
navy.mil. 

IJCAI 91, 12th Int’l Joint Conf. on Artifi¬ 
cial Intelligence, Aug. 24-30, Sydney, Aus¬ 
tralia. Cosponsors: Australian Computer 
Soc. et al. Contact Barbara J. Grosz, Aiken 
Computation Lab 20, Harvard Univ., 33 
Oxford St., Cambridge, MA 02138, phone 
(617) 495-3673, fax (617) 495-9837, e-mail 
grosz@endor.harvard.edu. 

Hot Chips III, Symp. on High- 
Performance Chips, Aug. 26-27, 
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Stanford, Calif. Sponsor: IEEE Computer 
Soc. Technical Committee on Microproces¬ 
sors and Microcomputers. Contact Martin 
Freeman, Philips Research Labs, Signetics 
MS 02, 811 E. Arques Ave., Sunnyvale, 

CA 94086, phone (408) 991-3591, fax (408) 
991-4077, e-mail mfreeman@sierra. 
stanford.edu; or Melissa Anderson, Silicon 
Graphics, 2011 N. Shoreline Blvd., PO Box 
7311, Mountain View, CA 94039-7311, 
phone (415) 335-1565, fax (415) 965-7651, 
e-mail mda@sgi.com. 

Tencon 91,1991 IEEE Region 10 
'5*7 Conf., Aug. 26-30, New Delhi, India. 
Contact H.L. Bajaj, B-101 Hillview Apts., 
Vasant Aihar, New Delhi 110057, India, 
phone 91 (11) 36-0412, fax 91 (11) 36-1018; 
or A.L. Lakshminarasimhan, AT&T Bell 
Labs, 480 Red Hill Rd„ No. HR 2E030, 
Middletown, NJ 07748, phone (201) 615- 
4524. 


j£jj\ 1991 Workshop on the High-Order 
Language Theorem-Proving System 
and Its Applications, Aug. 27-30, Davis, 
Calif. Sponsors: IEEE Computer Soc. 
Technical Committee on Design Automa¬ 
tion et al. Contact Myla Archer, Computer 
Science Division, Univ. of California at 
Davis, Davis, CA 95616, phone (916) 752- 
7583, fax (916) 752-4767, e-mail archer@ 
eecs.ucdavis.edu. 


Int’l Workshop on Field Programmable 
Logic and Applications, Sept. 4-6, Oxford, 
England. Contact Will Moore, Eng. Sci¬ 
ence Dept., Univ. of Oxford, Parks Road, 
Oxford, OX1 3PJ, England, UK, phone 44 
(865) 270-373, fax 44 (865) 270-309, e-mail 
cpdmail@vax.ox.ac.uk. 


Euro VHDL 91, Second European 
\*7 Conf. on Very High Density Logic, 
Sept. 8-11, Stockholm. Sponsor: Int’l Fed¬ 
eration for Information Processing. Con¬ 
tact Jean Mermet, IMT Technopole de 
Chateau-Gombert, 13451 Marseille, Cedex 
13, France, phone 33 (91) 05-44, fax 33 (91) 
05-4343. 


Third European Conf. on Electron and 
Optical-Beam Testing of Integrated Cir¬ 
cuits, Sept. 9-11, Como, Italy. Sponsor: 
IEEE North Italy Section. Contact Mar¬ 
cello Melgara, CSELT, via Reiss Romoli 
274,10148 Torino, Italy, phone 39 (11) 
2169-259, fax 39 (11) 2169-695. 

Third Conf. on Military Robotic Vehicles, 
Sept. 9-12, Medicine Hat, Alta., Canada. 
Cosponsors: Defence Research Establish¬ 
ment Suffield, Alberta Research Council. 
Contact Dave Mackay, DRES, Box 4000, 
Medicine Hat, Alta., Canada T1A 8K6, 
phone (403) 544-4732, fax (403) 544-3388. 


SSD 91. Second Symp. on Large Spa- 
v*7 tial Databases, Aug. 28-30, Zurich, 
Switzerland. Contact Hans-J. Schek, Inst, 
fur Information Systeme, Eth Zentrum, 
CH-8092 Zurich, Switzerland, phone 41 (1) 
254-7240, fax 41 (1) 262-3973, e-mail 
schek@inf.ethz.ch. 


September 1991 


iQij ASAP 91, Int’l Conf. on Application¬ 
's^ Specific Array Processors, Sept. 2-4, 

Barcelona, Spain. Sponsor: Princeton 
Univ. Contact S.Y. Kung, Electrical Eng. 
Dept., Princeton Univ., Princeton, NJ 
08554, phone (609) 258-3780, fax (609) 
258-3745. 


Eurographics 91, Conf. of the European 
Assoc, for Computer Graphics, Sept. 2-6, 

Vienna. Contact Eurographics 91, do In¬ 
terconvention, Austria Center Vienna, A- 
1450 Vienna, Austria, phone 43 (1) 2369- 
2643, fax 43 (1) 2369-648. 


Int’l Conf. on the Performance of Distrib¬ 
uted Systems and Integrated Communica¬ 
tion Networks, Sept. 10-12, Kyoto, Japan. 
Sponsor: Int’l Federation for Information 
Processing. Contact Yutaka Takahashi, 
Applied Math and Physics Dept., Faculty 
of Eng., Kyoto Univ., Kyoto 606, Japan, 
phone 81 (75) 3753-5493, fax 81 (75) 3761- 
2437, e-mail yutaka@kuamp.kyoto-u.ac.jp. 


Compsac 91,15th Int’l Computer 
Software and Applications Conf., 
Sept. 11-13, Tokyo. Cosponsor: Informa¬ 
tion Processing Soc. of Japan. Contact Ste¬ 
phen S. Yau, Univ. of Florida, CIS Dept., 
Rm. 301, Gainesville, FL 32611, phone 
(904) 335-8006 or (904) 392-1212, fax (904) 
392-1220, e-mail yau@cis.ufl.edu. 


AI 91, Frontiers in Innovative Computing 
for the Nuclear Industry, Sept. 15-18, Jack- 
son, Wyo. Cosponsors: Am. Nuclear Soc. 
Idaho Section et al. Contact Richard W. 
Lindsay, Argonne Nat’l Lab, PO Box 2528, 
Idaho Falls, ID 83403-2528, phone (208) 
526-7754, fax (208) 526-7623. 


® VLDB 91, 17th Int’l Conf. on Very 
Large Data Bases, Sept. 3-6, Barce¬ 
lona, Spain. Sponsors: IEEE Computer 
Soc. Technical Committee on Data Eng. 
et al. Contact Guy M. Lohman, IBM Al- 
maden Research Center, Dept. K55, Bldg. 
801, 650 Harry Rd„ San Jose, CA 95120- 
6099, Internet lohman@ibm.com, Bitnet 
lohman@almaden. 

SIGComm 91, ACM Conf. on Communica¬ 
tions Applications, Architectures, and Pro¬ 
tocols, Sept. 4-6, Zurich, Switzerland. Con¬ 
tact ACM, 11 W. 42nd St., New York, NY 
10036, phone (212) 869-7440. 


1991 Electronic Packaging Conf., Sept. 15- 

19, San Diego, Calif. Sponsor: Int’l Elec¬ 
tronics Packaging Soc. Contact IEPS, 114 
N. Hale St., Wheaton, IL 60187-5113, 
phone (708) 260-1044, fax (708) 260-0867. 


4rjii Fourth Artificial Intelligence Symp., 
Sept. 20-21, Fredericton, N.B., Cana¬ 
da. Sponsor: Univ. of New Brunswick. 
Contact Bradford G. Nickerson, Computer 
Science Faculty, Univ. of New Brunswick, 
PO Box 4400, Fredericton, N.B., Canada 
E3B 5A3, phone (506) 453-4566, fax (506) 
453-3566, e-mail bgn@unb.ca. 


First Int’l Workshop on the Econom- 
N5Z ics of Design and Test, Sept. 23-25, 

Austin, Texas. Sponsor: ACM. Contact 
Magdy Abadir, MCC CAD Program, 3500 
W. Balcones Center Dr., Austin, TX 
78759, phone (512) 338-3611, fax (512) 
338-3600; or A.P. Ambler, Brunei Univ., 
Dept, of Electrical Eng. and Electronics, 
Uxbridge, Middx, UB8 3PH, UK, phone 
(44) 895-74000, fax (44) 895-58728. 

ASIC 91, Fourth IEEE Int’l Applica¬ 
nt? tion-Specific Integrated Circuits 
Conf., Sept. 23-27, Rochester, N.Y. Spon¬ 
sor: IEEE Rochester Section. Contact 
Lynne M. Engelbrecht, ASIC 91,170 Mt. 
Read Blvd., Rochester, NY 14611, phone 
(716) 328-2310, fax (716) 436-9370. 

Pacific Rim Int'l Symp. on Fault- 
Tolerant Systems, Sept. 26-27, Ka¬ 
wasaki, Japan. Sponsor: Inst, of Electrical, 
Information, and Comm. Eng. Contact Sa- 
chio Naito, Electrical Eng. Dept., Nagaoka 
Univ. of Tech., 1603-1 Kamitomioka, Na¬ 
gaoka, Niigata, 940-21, Japan, phone 81 
(258) 46-6000, ext. 5110, fax 81 (258) 46- 
6506. 

IEEE/ACM Int’l Conf. on Develop- 
ing and Managing Expert System 
Programs and Projects, Sept. 30-Oct. 2, 

Washington, DC. Contact Jerald Feinstein, 
Mitre, 7325 Colshire Dr., McLean, VA 
22102, phone (703) 883-6236, fax (703) 
821-0701; or Larry Medsker, Computer 
Science and Information Systems Dept., 
American Univ., Washington, DC 20016. 

/£ji} 10th Symp. on Reliable Distributed 
V2P' Systems, Sept. 30-Oct. 2, Pisa, Italy. 
Contact Luca Simoncini, IEI-CNR, Via S. 
Maria 46, 56100 Pisa, Italy, phone 39 (50) 
553-159, fax 39 (50) 554-342; or Ozalp 
Babaoglu, Dip. di Matematica, Univ. di 
Bologna, Piazza di Porta S. Donato, 5, 
40127 Bologna, Italy, phone 39 (51) 354- 
430, fax 39 (51) 354-490, e-mail ozalp@ 
dm.unibo.it. 

First Int’l Conf. on Document Analy- 
sis and Recognition, Sept. 30-Oct. 2, 

Saint-Malo, France. Cosponsors: Assoc. 
Francaise pour la Cybernetique Econo- 
mique et Technique et al. Contact Guy 
Lorette, IRISA-Campus Universitaire de 
Beaulieu, 35042 Rennes Cedex, France, 
phone (33) 9936-2000, fax (33) 9938-32. 


ICAD 91, IFIP Working Conf. on Intelli¬ 
gent Computer-Aided Design, Sept. 30- 
Oct. 3, Columbus, Ohio. Sponsors: Int’l 
Federation for Information Processing et 
al. Contact Conferences and Institutes, 
Ohio State Univ., 175 Mount Hall, 1050 
Carmack Rd., Columbus, OH 43214, phone 
(614) 929-1301, fax (614) 292-0492, e-mail 
sarah_sieling@gate.ce.ohio-state. edu. 


October 1991 


July 1991 
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ter Burt, David Sarnoff Research Center, 
201 Washington Rd., Princeton, NJ 08540, 
e-mail burt@vision.sarnoff.com. 

OOPSLA 91, Sixth Conf. on Object- 
Oriented Programming Systems, Lan¬ 
guages, and Applications, Oct. 6-11, Phoe¬ 
nix, Ariz. Sponsor: ACM. Contact John 
Richards, IBM T.J. Watson Research Cen¬ 
ter, PO Box 704, Yorktown Heights, NY 
10598, phone (914) 784-7616; or Dan Stein- 
bach, Steinbach and Co., 1 Pleasant St., 
Maynard, MA 01754, phone (508) 897- 
8661. 


jggj CSEE 91, Fifth Conf. on Software 
Eng. Education, Oct. 7-8, Pittsburgh. 
Sponsor. Software Eng. Inst. Contact 
James E. Tomayko, SEI, Carnegie Mellon 
Univ., 4500 Fifth Ave., Pittsburgh, PA 
15213-3890, phone (412) 268-6806, fax 
(412) 268-5758, e-mail jet@sei.cmu.edu. 

11th IEEE Symp. on Mass Storage 
Systems, Oct. 7-10, Monterey, Calif. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Mass Storage Systems and 
Tech. Contact Bernard T. O’Lear, NCAR, 
PO Box 3000, Boulder, CO 80307, phone 
(303) 497-1268, fax (303) 497-1137. 


Canada. Sponsors: IEEE Computer Soc., 
ACM SIGSoft. Contact Nancy Leveson, 
Computer Science Dept., Univ. of Califor¬ 
nia, Irvine, CA 92717, phone (714) 856- 
5517, e-mail nancy@ics.uci.edu. 

First Int’l Conf. on Artificial Intelli- 
vlz gence Applications on Wall St., Oct. 
9-11, New York City. Sponsor: Polytechnic 
Univ., Brooklyn. Contact Mary Bianchi, 
Polytechnic Univ., 333 Jay St., Brooklyn, 
NY 11201, phone (718) 260-3360, fax (718) 
260-3136. 

/ijiv IEEE Int’l Workshop on Visual Lan- 
guages, Oct. 9-11, Kobe, Japan. 
Sponsor: IEEE Computer Soc. Contact 
Shi-Kuo Chang, Computer Science Dept., 
Univ. of Pittsburgh, Pittsburgh, PA 15260, 
phone (412) 624-8423, fax (412) 624-8465. 

Workshop on Experimental Distri- 
'Ss buted Systems, Oct. 12, Huntsville, 
Ala. Contact Raif M. Yanney, TRW, 1 
Space Park, DH2/2328, Redondo Beach, 
CA 90278, phone (213) 764-6033. 

|£ji RIDT 91, Second Int'l Workshop on 
Raster Imaging and Digital Typogra¬ 
phy, Oct. 14-15, Boston. Cosponsor: Univ. 
of Massachusetts. Contact Robert A. Mor¬ 
ris, Math and Computer Science Dept., 
Univ. of Massachusetts at Boston, Harbor 
Campus, Boston, MA 02125-3393, phone 
(617) 287-6466, e-mail ridt91-request@cs. 
umb.edu. 

ICCD 91, IEEE Int’l Conf. on Com- 
puter Design, Oct. 14-16, Cambridge, 
Mass. Cosponsors: IEEE Computer Soc. 
and IEEE Circuits and Systems Soc. Con¬ 
tact ICCD 91, IEEE Computer Soc., 1730 


Massachusetts Ave. NW, Washington, DC 
20036-1903, phone (202) 371-1013. 

16th Conf. on Local Computer Net- 
works, Oct. 14-17, Minneapolis, 

Minn. Cosponsor: IEEE Computer Soc. 
Technical Committee on Computer Comm. 
Contact James F. Mollenauer, Technical 
Strategy Associates, 37 Silver Birch Rd., 
Newton, MA 02168, phone and fax (617) 
244-0077. 

CSM 91, Conf. on Software Mainte- 
nance, Oct. 14-17, Sorrento, Italy. 
Cosponsor: IEEE. Contact Vaclav Rajlich, 
Computer Science Dept., Wayne State 
Univ., Detroit, MI 48202, phone (313) 577- 
5423, fax (313) 577-6868, e-mail vtr@cs. 
wayne.edu; John Munson, Computer Sci¬ 
ence Dept., Univ. of West Florida, Pensa¬ 
cola. FL 32514; or Malcolm Munro, Centre 
for Software Maintenance, Univ. of 
Durham, Durham, DH1 3LE, England, 
phone 44 (091) 374-2634, e-mail malcolm. 
munro@uk.ac.durham. 

Int’l Computer Music Conf., Oct. 16-20, 

Montreal. Sponsor: Computer Music As¬ 
soc. Contact Larry Austin, CMA, PO Box 
1634, San Francisco, CA 94101-1634, 
phone (817) 566-2235. 

Int’l Workshop on Object Orienta- 
tion in Operating Systems, Oct. 17- 

18, Palo Alto, Calif. Sponsor: IEEE Com¬ 
puter Soc. Technical Committee on Oper¬ 
ating Systems. Contact Vincent Russo, 
Computer Science Dept., Purdue Univ., 
West Lafayette, IN 47907, phone (317) 
494-6008, fax (317) 494-0737. 

j^ii) Visualization 91, Oct. 22-25, San 

Diego, Calif. Sponsor: IEEE Com¬ 
puter Soc. Technical Committee on Com¬ 
puter Graphics. Contact Bruce Brown, Or¬ 
acle, 500 Oracle Pkwy., MD 40P12, 
Redwood Shores, CA 94065, phone (415) 
726-0983, fax (415) 506-7200; or Gregory 
M. Nielson, Computer Science Dept., Ari¬ 
zona State Univ., Rural Road and Univer¬ 
sity, Tempe, AZ 85287-5406, phone (602) 
965-2785. 

10th Int’l Conf. on Entity-Relation- 
ship Approach, Oct. 23-25, San Fran¬ 
cisco. Sponsor: ER Inst, et al. Contact Ter¬ 
ry Moriarty, Bank of Am., PO Box 37000, 
#3439, San Francisco, CA 94137, phone 
(415) 675-5250; or Toby J. Teorey, EECS 
Dept., Univ. of Michigan, Ann Arbor, MI 
48109-2122, phone (313) 763-5216, e-mail 
teorey@ub.cc.umich.edu. 

Sixth Int’l Workshop on Software 
Specification and Design, Oct. 25-26, 

Como, Italy. Contact C. Ghezzi, Dip. di 
Elettronica, Politecnico di Milano, Piazza 
Leonardo Da Vinci 32, 20133 Milano, Ita¬ 
lia, e-mail relett24@imipoli.bitnet; or Jean- 
Pierre Finance, CRIN, Campus Scien- 
tifique, BP 239 54000 Nancy, France, 
e-mail finance@loria.crin.fr. 

ITC 91, Int’l Test Conf., Oct. 26-Nov. 

1, Nashville, Tenn. Cosponsor: IEEE 
Philadelphia Section. Contact Doris Tho¬ 


mas, PO Box 264, Mt. Freedom, NJ 07970, 
phone (201) 895-5260, fax (201) 896-7265; 
or IEEE Computer Soc., 1730 Massachu¬ 
setts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013. 

gii ILPS 91, Int’l Logic Programming 
Symp., Oct. 28-31, San Diego, Calif. 
Sponsor: Assoc, of Logic Programming. 
Contact Kenneth Kahn or Vijay Saraswat, 
Xerox PARC, 3333 Coyote Hill Rd., Palo 
Alto, CA 94304, Kahn’s phone (415) 494- 
4390, Saraswat’s phone (415) 494-4747, fax 
(415) 494-4334, e-mail ilps91@parc.xerox. 


gi) ISCIS VI, Sixth Int’l Symp. on Com- 
vlz puter and Information Sciences, Oct. 
30-Nov. 2, Ankara, Turkey. Sponsors: Bil- 
kent Univ., IEEE Turkey Chapter. Con¬ 
tact Mehmet Baray, Bilkent Univ., Com¬ 
puter Eng. and Information Sciences 
Dept., Bilkent 06533 Ankara, Turkey, 
phone (90) 4-266-4133, fax 90 (4) 266-4127, 
e-mail iscis@trbilun.bitnet. 


November 1991 

gij 25th Asilomar Conf. on Signals, Sys- 
vEZ terns, and Computers, Nov. 4-6. Pa¬ 
cific Grove, Calif. Sponsors: Naval Post¬ 
graduate School, San Jose State Univ. 
Contact Frederic J. Harris, Electrical and 
Computer Eng. Dept., San Diego State 
Univ., San Diego, CA 92182-0190, (619) 
594-6162. 

TAI 91, Third IEEE Computer Soc. 
Conf. on Tools for Artificial Intelli¬ 
gence, Nov. 5-8, San Jose, Calif. Contact 
Benjamin Wah, Coordinated Science Lab, 
MC 228, Univ. of Illinois, 1101 W. Spring- 
field Ave., Urbana, IL 61801-3082, phone 
(217) 333-3516, fax (217) 244-1764, e-mail 
wah% aquinas@cso.uicu.edu; or Nikolaus 
G. Bourbakis, 4138 Moonflower Ct., San 
Jose, CA 95135, phone (408) 270-3455. 

g^i Conf. on Organizational Computing 

vl^ Systems, Nov. 5-8, Atlanta. Sponsors: 
IEEE Computer Soc. Technical Commit¬ 
tee on Office Automation, ACM SIGOIS, 
Int’l Federation for Information Process¬ 
ing. Contact Frederick H. Lochovsky, 

Hong Kong Univ. of Science and Tech., 
Computer Science Dept., 5/F World Ship¬ 
ping Center, 7 Canton Rd., Hong Kong, 
phone (852) 302-1642, fax (852) 736-8801. 

ICCAD 91, IEEE Int’l Conf. on 
Computer-Aided Design, Nov. 11-14, 

Santa Clara, Calif. Cosponsor: IEEE Cir¬ 
cuits and Systems Soc. Contact ICCAD 91 
Secretary, MP Associates, 7490 Clubhouse 
Rd., Suite 102, Boulder, CO 80301, phone 
(303) 530-4562. 

gki Micro 24, 24th ACM/IEEE Int’l 

Symp. and Workshop on Microarchi¬ 
tecture, Nov. 18-20, Albuquerque, N.M. 
Contact Yashwant K. Malaiya, Computer 
Science Dept., Colorado State Univ., Fort 
Collins, CO 80523, phone (303) 491-7031, 
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Supercomputing 91, Nov. 18-22, 

Albuquerque, N.M. Cosponsor: 
ACM. Contact Raymond L. Elliott, Com¬ 
puting and Comm. Div., MS B260, Los 
Alamos Nat’l Lab, Los Alamos, NM 87545, 
phone (505) 667-1449, fax (505) 665-4361, 
e-mail rle@lanl.gov; or Supercomputing 91, 
IEEE Computer Soc., 1730 Massachusetts 
Ave. NW, Washington, DC 20036-1903, 
phone (202) 371-1013. 


December 1991 


Third IEEE Int'l Symp. on Parallel 
VE? and Distributed Processing, Dec. 1-5, 

Dallas. Sponsors: IEEE Computer Soc., 
IEEE Dallas Section, ACM SIGArch. 
Contact Sartaj Sahni, CIS Dept., CSE 301, 
Univ. of Florida, Gainesville, FL 32611, 
phone (904) 392-1527, fax (904) 392-1220; 
or Behrooz Shirazi, Univ. of Texas at Ar¬ 
lington, Computer Science Eng. Dept., 

Box 19015, Arlington, TX 76019-0015, 
phone (817) 273-3605, fax (817) 273-2548, 
e-mail shirazi@evax.utarl.edu. 

12th IEEE Symp. on Real-Time Sys- 
sg? terns, Dec. 3-6, San Antonio, Texas. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Real-Time Computing. 
Contact Jane S.W. Liu, Computer Science 
Dept., Univ. of Illinois, 1304 W. Spring- 
field Ave., Urbana, IL 61801, phone (217) 
333-0135, e-mail janeliu@cs.uiuc.edu. 

® Int’l Conf. on Parallel and Distri¬ 
buted Information Systems, Dec. 4-6, 

Miami Beach, Fla. Cosponsors: IEEE 
Computer Soc. et al. Contact Amit Sheth, 
Bellcore, 1J-210, 444 Hoes Ln., Piscataway, 
NJ 08854, phone (908) 699-3300, fax (908) 
699-9011, e-mail amit@ctt.bellcore.com. 

1991 Winter Simulation Conf., Dec. 
sg? 8-11. Phoenix, Ariz. Sponsor: ACM. 
Contact Robert Crain, Wolverine Soft¬ 
ware, 4115 Annandale Rd., Suite 200, An- 
nandale, VA 22003. 

World Congress on Expert Systems, 
v5y Dec. 16-19, Orlando, Fla. Cospon¬ 
sors: Int’l Assoc, of Knowledge Engineers 
et al. Contact World Congress on Expert 
Systems, do Congress Secretariat, Congrex 
(USA), 7315 Wisconsin Ave., Suite 404E, 
Bethesda, MD 20814, phone (301) 469- 
3355, fax (301) 469-3360. 


January 1992 


© Fifth Int’l Conf. on VLSI Design, 
Jan. 4-7, Bangalore, India. Sponsor: 
VLSI Soc. of India et al. Contact Asoke K. 
Laha, Cadence Design Systems, Systems 
Division, 2 Lowell Research Center Dr., 
Lowell, MA 01852-4995, phone (508) 934- 


0233, fax (508) 441-1109, e-mail laha@ 
cadence.com; or Lalit M. Patnaik, Comput¬ 
er Science and Automation, Indian Inst, of 
Science, Bangalore, 560012, India, phone 
91 (812) 342-451, e-m a il lalit%vigyan@ 
shakti.emet.in. 

jSSij Hawaii Int’l Conf. on Systems Sci- 

ences, Jan. 7-10, Koloa, Hawaii. Co¬ 
sponsors: IEEE, ACM. Contact Luqi, 
Computer Science Dept, Naval Postgradu¬ 
ate School, Monterey, CA 93940, phone 
(408) 646-2468. 

PADS, Sixth Workshop on Parallel 

and Distributed Simulation, Jan. 20- 

22, Newport Beach, Calif. Joint sponsors: 
IEEE, ACM, Soc. for Computer Simula¬ 
tion. Contact Paul Reynolds, Computer 
Science Dept., Olsson Hall, Univ. of Vir¬ 
ginia, Charlottesville, VA 22903, phone 
(804) 924-1039, e-mail pfr@louisxiv.ipc. 
virginia.edu. 

IEEE Int’l Conf. on Wafer-Scale In- 
vs? tegration, Jan. 22-24, San Francisco. 
Sponsors: IEEE Computer Soc., IEEE 
Components, Hybrids, and Manufacturing 
Tech. Soc. Contact Peter W. Wyatt, MIT 
Lincoln Lab, B-153, Box 73, Lexington, 
MA 02173-9108, phone (617) 981-7232. 


February 1992 

ICDE 92, Eighth Int’l Conf. and 
Workshop on Data Eng., Feb. 1-7, 

Phoenix, Ariz. Sponsor: IEEE Computer 
Soc. Technical Committee on Data Eng. 
Contact (for the conference) Nick J. Cer- 
cone. Center for Systems Sciences, Simon 
Fraser Univ., Burnaby, B.C., Canada V5A 
1S6, phone (604) 291-3229, e-mail nick@cs. 
sfu.ca; or (for the workshop on research is¬ 
sues) Clement Yu, Electrical Eng. and 
Computer Science Dept., Univ. of Illinois 
at Chicago, Chicago, IL 60680, phone (312) 
996-2318, fax (312) 413-0024. 

RIDE 92, Int’l Workshop on Re¬ 
vs^ search Issues in Data Eng., Feb. 2-3, 

Mission Palms, Ariz. Contact Clement Yu, 
EECS Dept., Univ. of Illinois at Chicago, 
Chicago, IL 60680, phone (312) 996-2318, 
fax (312) 413-0024, e-mail yu@uicbert. 
eecs.uic.edu. 

Compcon Spring 92, Feb. 24-28, San 

Francisco. Contact Compcon Spring 
92, IEEE Computer Soc., 1730 Massachu¬ 
setts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013. 


CAIA 92, Eighth IEEE Conf. on 
v2e 7 Artificial Intelligence for Applica¬ 
tions, Mar. 2-6, Monterey, Calif. Contact 
CAIA 92, IEEE Computer Soc., 1730 Mas¬ 
sachusetts Ave. NW; Washington, DC 


20036-1903, phone (202) 371-1013, fax 
(202) 728-0884. 

Third Int’l Conf. on Data and 

Knowledge Systems for Manufactur¬ 
ing Eng., Mar. 9-13. Cosponsors: Assoc. 
Francaise pour la Cybernetique Econom- 
ique et Technique et al. Contact INS A, 20 
Av. Albert Einstein, 69621 Villeurbanne, 
France, phone 33 (72) 438-172, fax 33 (72) 
440-800. 

Fourth Int’l Conf. on Strategic Soft- 

ware Systems, Mar. 10-11, Hunts¬ 
ville, Ala. Cosponsors: IEEE Computer 
Soc. Huntsville Chapter, Univ. of Alabama 
in Huntsville. Contact Ann H. Yelle, Univ. 
of Alabama in Huntsville, Continuing Edu¬ 
cation Division, Conferences (SSS-92), 
Bevill Center 289-A, Huntsville, AL 35899, 
phone (800) 448-4035 or (205) 895-6372, 
fax (205) 895-6760. 

EDAC 92, European Conf. on De- 
vg7 sign Automation, Mar. 16-19, Brus¬ 
sels. Cosponsors: EDAC Assoc, et al. Con¬ 
tact EDAC 92 Secretariat, CEP Consult¬ 
ants, 26-28 Albany St., Edinburgh EH1 
3QH, UK, phone 44 (31) 557-2478, fax 44 
(31) 557-5749. 

j£S»jS IPPS 92, Sixth Int’l Parallel Pro- 
vS7 cessing Symp., Mar. 23-26, Beverly 
Hills, Calif. Contact Larry H. Canter, 
Computer Systems Approach, 1140 S. Ray¬ 
mond Ave., Suite B, Fullerton, CA 92631, 
phone (714) 738-3414, fax (714) 738-3470. 


April 1992 


PCCC 92,11th IEEE Int’l Phoenix 
Conf. on Computers and Communi¬ 
cations, Apr. 1-3, Scottsdale, Ariz. Cospon¬ 
sors: IEEE Comm. Soc. et al. Contact 
Ralph Martinez, Univ. of Arizona, Electri¬ 
cal and Computer Eng. Dept., Tucson, AZ 
85721, phone (602) 621-6174, e-mail 
martinez%ecevax@rvax.ccit.arizona.edu; 
or Joseph Urban, Computer Science and 
Eng. Dept., Arizona State Univ., Tyler 
Mail-ECG 252, Tempe, AZ 85287-5406, 
phone (602) 965-2774, fax (602) 965-2751, 
e-mail jurban@asuvax.eas.asu.edu. 

@ ICCL 92, Int’l Conf. on Computer 
Languages, Apr. 20-23, San Fran¬ 
cisco. Sponsor: IEEE Computer Soc. Tech¬ 
nical Committee on Computer Languages. 
Contact Mario Barbacci, Software Eng. 
Inst., Carnegie Mellon Univ., Pittsburgh, 
PA 15213, phone (412) 268-7704, fax (412) 
268-5758. 

/Qi} Third Workshop on Workstation Op- 
erating Systems, Apr. 23-24. Sponsor: 
IEEE Computer Soc. Technical Commit¬ 
tee on Operating Systems. Contact Joseph 
Boykin, Encore Computer, 257 Cedar Hill 
St., Marlborough, MA 01752, phone (508) 
460-0500, fax (508) 485-0709. 
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May 1992 


(fTi) CHI 92, Conf. on Human Factors in 
vSZ Computing, May 3-7, Monterey, 
Calif. Sponsor: ACM. Contact Assoc, for 
Computing Machinery, 11 W. 42nd St., 
New York, NY 10036, phone (212) 869- 
7440. 

IEEE Infocom 92,11th Conf. on 
vE7 Computer Comm., May 4-8, Flo¬ 
rence, Italy. Cosponsor: IEEE Comm. Soc. 
Contact L. Fratta, Politecnico di Milano, 
do Cefriel, Via Emanueli, 15, 20126 Mila¬ 
no, Italy, phone 39 (2) 2399-3578, fax 39 
(2) 2399-3587, e-mail fratta@imicefr.bitnet; 
or J. Kurose, Computer and lnformation 
Science Dept., Univ. of Massachusetts, 
Amherst, MA 01003, phone (413) 545- 
1585, e-mail kurose@cs.umass.edu. 

( ^f^ | Comp Euro 92, IEEE Int’I Conf. on 
Advanced Computer Tech., Reliable 
Systems, and Applications, May 4-8, The 

Hague, The Netherlands. Cosponsors: 
IEEE Region 8, IEEE Benelux. Contact 
G.J. Arink. Philips Medical Systems. PO 
Box 10.000, 5680 DA Best, The Nether¬ 
lands, phone 31 (40) 762-060. 

® ICSE 92,14th Int’I Conf. on Soft¬ 
ware Eng., May 11-15, Melbourne, 
Australia. Cosponsors: IEEE Computer 
Soc. et al. Contact A.Y. Montgomery, 
Computer Science Dept., Royal Mel¬ 
bourne Inst, of Tech., PO Box 2476V, Mel¬ 
bourne 3001, Victoria, Australia, phone 61 
(3) 660-2943, fax 61 (3) 662-1617, e-mail 
aym@goanna.cs.rmit.oz.au. 

22nd Int’I Symp. on Multiple-Valued 
viz Logic, May 27-29, Sendai, Japan. 
Sponsors: IEEE Computer Soc. Technical 
Committee on Multiple-Valued Logic. 
Contact Tatsuo Higuchi, EE Dept., To- 
huku Univ., Aoba, Aramaki, Sendai 980, 
Japan, phone (022) 222-1800. 


June 1992 

FGCS 92, Int’I Conf. on Fifth- 
viz Generation Computer Systems, June 
1-5, Tokyo. Cosponsors: Information Pro¬ 
cessing Soc. of Japan et al. Contact Hidehi- 
ko Tanaka, Univ. of Tokyo, 3-1 Hongo 7- 
chome, Bunkyo-ku, Tokyo 113, Japan, 
phone 81 (33) 3812-2111, ext. 6663, fax 81 
(33) 3818-5706. 

/gjjt DAC 92, IEEE/ACM Design Auto- 

mation Conf., June 8-12, Anaheim, 
Calif. Contact DAC 92, MP Associates, 
7490 Clubhouse Rd„ Boulder, CO 80301, 
phone (303) 530-4333. 

Sixth Int’I Workshop on Scientific 
viz and Statistical Database Manage¬ 
ment, June 9-11, Zurich, Switzerland. Co¬ 
sponsor: ACM SIGMOD. Contact H. 
Hinterberger, Inst, for Scientific Comput¬ 
ing, ETH Zentrum, CH-8093 Zurich, Swit¬ 
zerland, phone 41 (1) 254-7436, fax 41 (1) 
262-3973. 


CALL FOR PAPERS 


IEEE Micro invites authors to sub- 
v5z mit general-interest and theme-issue 
papers for publication in 1992 issues. 
Themes include European industry, DSPs, 
associative memories and processors, and 
ICs for HDTV. Submit six copies of each 
paper to Editor-in-Chief Dante Del Corso, 
Dipartimento di Elettronica, Politecnico di 
Torino, C.so Duca degli Abruzzi, 24,10129 
Torino, Italy, e-mail delcorso@polito.it; or 
Ashis Khan, Associate EIC, Mips Com¬ 
puter Systems, 950 DeGuigne Dr., Sunny¬ 
vale, CA 94086, phone (408) 524-7171, 
e-mail ashis@mips.com. For author guide¬ 
lines, dial (714) 821-8380. 

IEEE Int’I Symp. on Industrial Electron¬ 
ics: May 25-29,1992, Xian, China. Cospon¬ 
sors: IEEE Industrial Electronics Soc. et 
al. Submit three copies of 300 to 500-word 
summary by July 31,1991, and final manu¬ 
script by Jan. 31,1992, to J.D. Irwin, Elec¬ 
trical Eng. Dept., Auburn Univ., Auburn, 
AL 36849, phone (205) 844-1810, fax (205) 
844-1809 (for authors outside China); or 
Sheng-wu Liu, Library, Northwestern 
Polytechnical Univ., Xian 710071, China, 
phone 1 (29) 533-71, ext. 2926, fax 1 (29) 
711-959 (for authors in China). 

Second Int’I Symp. on Artificial Intelli¬ 
gence and Math.: Jan. 5-8,1992, Fort Lau¬ 
derdale, Fla. Cosponsors: Florida Atlantic 
Univ. et al. Submit five copies of extended 
abstract by July 31,1991, to Jean-Louis 
Lassez, IBM T.J. Watson Research Center, 
H1-A12, PO Box 704, Yorktown Heights, 
NY 10598, phone (914) 784-7841, fax (914) 
784-6307, e-mail jll@watson.ibm.com. 

Simulation Tech. Conf. Int’I 1991: Oct. 21- 
23,1991, Orlando, Fla. Sponsor: Soc. for 
Computer Simulation. Submit final paper 
by Aug. 1,1991, to Mary Lou Padgett, 1165 
Owens Rd., Auburn, AL 36830, phone 
(205) 821-2472. 

Second Int’I Bankai Workshop: Oct. 14-16, 
1991, Brussels. Sponsor: Soc. for World¬ 
wide Interbank Financial Telecommunica¬ 
tion. Submit 1,000-word extended abstract 
or full paper by Aug. 1,1991, to B. Dirai¬ 
son, Al Lab, SWIFT, Ave. Adele, 1-B1310 
La Hulpe, Belgium. 

Second Great Lakes Computer Science 
Conf.: Oct. 17-19,1991, Kalamazoo, Mich. 
Sponsor: Western Michigan Univ. Submit 
four copies of 500-word summary and one 
50-word abstract by Aug. 1,1991, to Alfred 
Boals, Computer Science Dept., Western 
Michigan Univ., Kalamazoo, MI 49008, 
phone (616) 387-5645, fax (616) 387-3999, 
e-mail glscs@sol.cs.wmich.edu. 


Minn. Cosponsor: IEEE Computer Soc. 
Technical Committee on Computer Comm. 
Submit five copies of camera-ready version 
by Aug. 2,1991, to James F. Mollenauer, 
Technical Strategy Associates, 37 Silver 
Birch Rd., Newton, MA 02168, phone and 
fax (617) 244-0077. 

Symp. on Document Analysis and Infor¬ 
mation Retrieval: Mar. 16-18,1992, Las 
Vegas, Nev. Submit seven copies of paper 
by Aug. 2,1991, to William L. Brogan, 
Electrical Eng. Dept., Univ. of Nevada at 
Las Vegas, 4505 Maryland Pkwy., Las Ve¬ 
gas, NV 89154, phone (702) 597-4184, 
e-mail eewlb@cs.unlv.edu (papers on docu¬ 
ment analysis); or Kazem Taghva, Com¬ 
puter Science Dept., UNLV, 4505 Mary¬ 
land Pkwy., Las Vegas, NV 89154, phone 
(702) 739-3338, e-mail taghva@cs.unlv.edu 
(papers on information retrieval). 

Workshop on Multimedia Information Sys¬ 
tems: Feb. 7-8,1992, Phoenix, Ariz. Submit 
paper by Aug. 16,1991, to P. Bruce Berra, 
ECE Dept., Syracuse Univ., Syracuse, NY 
13244, phone (315) 443-4445. 

Working Conf. on Information System 
Concepts: Apr. 13-15,1992, Alexandria, 
Egypt. Sponsor: Int’I Federation for Infor¬ 
mation Processing. Submit five copies of 
manuscript by Aug. 16,1991, and camera- 
ready paper by Dec. 13,1991, to Eckhard 
D. Falkenberg, Information Systems Dept., 
Univ. of Nijmegen, Toernooiveld 1, NL- 
6525 ED Nijmegen, The Netherlands, fax 
31 (80) 553-450, e-mail ef@cs.kun.nl. 

1992 Symp. on Compound Semiconductor 
Physics and Devices: Mar. 23-27,1992, 
Somerset, N.J. Sponsor: Int’I Soc. for Opti¬ 
cal Eng. Submit abstract by Aug. 26,1991, 
and manuscript by Apr. 27,1992, to SPIE, 
PO Box 10, Bellingham, WA 98227-0010, 
phone (206) 676-3290, fax (206) 647-1445 
(in North Am.); SPIE, Xantner Strasse 22, 
D-1000 Berlin 15, Germany, phone (49) 
228-219062 (in Europe); or SPIE, c/o OTO 
Research, Takeuchi Bldg., 1-34-12 Taka- 
tanobaba, Shinjuku-ku, Tokyo 160, Japan, 
phone 81 (03) 3208-7821, fax 81 (03) 3200- 
2889 (in the Far East, Australia, and New 
Zealand). 

jjgj!) CAIA 92, Eighth IEEE Conf. on Ar- 
v§Z tificial Intelligence for Applications: 

Mar. 2-6,1992, Monterey, Calif. Submit six 
copies of paper by Aug. 30,1991, and 
camera-ready paper by Dec. 11,1991, to 
Jan Aikins, Aion, 101 University Ave., 

Palo Alto, CA 94301, phone (415) 328- 
9595, fax (415) 328-0624, e-mail aikins@ 
cup.portal.com. 

IEEE Design & Test plans a special 
viz issue on mixed analog/digital systems 
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in its March 1992 issue. Submit papers (25 
double-spaced pages, including figures) on 
design synthesis (focus on analog), archi¬ 
tectures, trade-offs between analog and 
digital, test issues, CAD tools, (such as 
place/route and mixed-mode simulation), 
new tester complexity (such as features 
needed for the tester and related prob¬ 
lems), and quality assurance by Sept. 1, 
1991, to Manuel d’Abreu, GE R&D, 1 Riv¬ 
er Rd„ PO Box 8, KW-C308, Schenectady, 
NY 12301, phone (518) 387-7097, fax (518) 
387-5299, e-mail dabreu@crd.ge.com. 


12th IEEE Symp. on Real-Time Sys- 
terns: Dec. 3-6,1991, San Antonio, 
Texas. Sponsor: IEEE Computer Soc. 
Technical Committee on Real-Time Com¬ 
puting. Submit five copies of extended 
abstract by Sept. 2,1991, to Lui Sha, Soft¬ 
ware Eng. Inst., Carnegie Mellon Univ., 
4500 Fifth Ave., Pittsburgh, PA 15213, 
phone (412) 268-5875, e-mail sha@sei.cmu. 
edu. 


/jriii EDAC 92, European Conf. on De- 
sign Automation: Mar. 16-19,1992, 
Brussels. Cosponsors: EDAC Assoc, et al. 
Submit nine copies of full manuscript by 
Sept. 2,1991, and final version by Dec. 2, 
1991, to Hugo De Man, c/o CEP Consult¬ 
ants, 26-28 Albany St., Edinburgh EH1 
3QH, UK, phone 44 (31) 557-2478, fax 44 
(31) 557-5749. 

ICSE 92,14th Int’l Conf. on Soft- 
ware Eng.: May 11-15,1992, Mel¬ 
bourne, Australia. Cosponsors: IEEE 
Computer Soc. et al. Submit six copies of 
full paper or experience report by Sept. 6, 
1991. to A.Y. Montgomery, Computer Sci¬ 
ence Dept., Royal Melbourne Inst, of 
Tech., PO Box 2476V, Melbourne 3001, 
Victoria, Australia, phone 61 (3) 660-2943, 
fax 61 (3) 662-1617, e-mail aym@goanna. 
cs.rmit.oz.au. 


Third Conf. on Applied Natural Language 
Processing: Apr. 1-3,1992, Trento, Italy. 
Sponsor: Assoc, for Computational Lin¬ 
guistics. Submit six copies of full paper and 
16 copies of abstract by Sept. 10,1991, to 
Oliviero Stock, I.R.S.T., 38050 Povo, Tren¬ 
to, Italy, phone 39 (461) 814-444, fax 39 
(461) 810-851, e-mail stock@irst.it (in 
Europe and Asia); or Madeleine Bates, 
BBN Systems and Technologies, 10 Moul¬ 
ton St., Cambridge, MA 02138, phone 
(617) 873-3634, fax (617) 873-3776, e-mail 
bates@bbn.com (in the Americas and other 
continents). 

Fuzz IEEE 92, IEEE Int’l Conf. on Fuzzy 
Systems: Mar. 8-12,1992, San Diego, Calif. 
Sponsor: IEEE Neural Network Council. 
Submit eight copies of paper by Sept. 13, 
1991, to Didier Dubois/Henri Prade, IRIT, 
Univ. Paul Sabatier, 118 route de Nar- 
bonne, 31062 Toulouse Cedex, France, 
phone (33) 6155-6331, fax (33) 6155-6239. 


Computer Science Dept., Colorado State 
Univ., Fort Collins, CO 80523, phone (303) 
491-7031, fax (303) 491-2293, e-mail 
malaiya@ravi.cs.colostate.edu; or K.S. 
Raghunathan, Microelectronic and Com¬ 
puter Division, Indian Telephone Indus¬ 
tries, Bangalore, 560016, India, phone 91 
(812) 563-211, fax 91 (812) 572-824. 

Micro 24, 24th ACM/IEEE Int’l 

Symp. and Workshop on Microarchi¬ 
tecture: Nov. 18-20,1991, Albuquerque, 
N.M. Submit four copies of final version by 
Sept. 17,1991, to (by geographical region) 
Andrew Wolfe, Electrical and Computer 
Science Dept., Carnegie Mellon Univ., 
Pittsburgh, PA 15213-3890, phone (412) 
268-7102, fax (412) 268-2860, e-mail 
wolfe@ece.cmu.edu; Toshio Nakatani, 

IBM Japan, 5-19, Sanbancho, Chiyoda-ku, 
Tokyo 102, Japan, phone 81 (03) 288-8409, 
fax 81 (03) 265-4251, e-mail nakatani® 
trlvm3.iinusl.ibm.com or nakatani@ 
jpntscvm.bitnet; or Hans Mulder, Electri¬ 
cal Eng. Dept., Delft Univ. of Tech., PO 
Box 5031, 2600 GA Delft, The Nether¬ 
lands, phone 31 (0) 1578-5021, fax 31 (0) 
1578-4898, e-mail hansm@duteca.et. 
tudelft.nl. 


European Forth Modification Lab Conf.: 

Oct. 11-13,1991, Marianske Laznc, Czech¬ 
oslovakia. Submit paper by Sept. 23,1991, 
to Marina Kern/Klaus Schteisiek-Kern, 
Uhlenhorster Weg 3, D-2000 Hamburg 76, 
Germany, 49 (40) 229-6441, fax 49 (40) 
229-7205. 


/Qii IEEE Software seeks articles for a 
special issue in 1992 about the appli¬ 
cations of software-reliability models to 
assess and certify software quality and 
dependability during product develop¬ 
ment. Case studies and experience reports 
are particularly welcome. Submit seven 
copies of article by Oct. 1,1991, to Pradip 
K. Srimani or Yashwant K. Malaiya, Com¬ 
puter Science Dept., Colorado State Univ., 
Fort Collins, CO 80525, fax (303) 491-2293, 
Internet srimani@cs.colostate.edu or 
malaiya@cs.colostate.edu. For author 
guidelines, contact Karen Potes, IEEE 
Software, PO Box 3014, Los Alamitos, CA 
90720-1264, phone (714) 821-8380, fax 
(714) 821-4010, Internet w.c.ops@ 
compmail.com. 

IEEE Int’l Conf. on Wafer-Scale In- 
tegration: Jan. 22-24,1992, San Fran¬ 
cisco. Sponsors: IEEE Computer Soc., 
IEEE Components, Hybrids, and Manu¬ 
facturing Tech. Soc. Submit six copies of 
full camera-ready text by Oct. 1,1991, to 
Peter W. Wyatt, MIT Lincoln Lab, B-153, 
Box 73, Lexington, MA 02173-9108, phone 
(617) 981-7232 (in the Americas); R. Mike 
Lea, Brunei Univ., Uxbridge UB8 3PH, 

UK (in Europe); or Tadashi Sasaki, Sharp 
Corp., 8, Ichigaya, Hachiman-cho, Shin- 
juku-ku, Tokyo 162, Japan (in Asia). 


E. Urban, Computer Science and Eng. 
Dept., Arizona State Univ., Tyler Mail- 
ECG 252, Tempe, AZ 85287-5406, phone 
(602) 965-2774, fax (602) 965-2751, e-mail 
jurban@asuvax.eas.asu.edu. 

PADS, Sixth Workshop on Parallel 
W and Distributed Simulation: Jan. 20- 
22,1992, Newport Beach, Calif. Joint spon¬ 
sors: IEEE et al. Submit six copies of 
camera-ready copy by Oct. 15,1991, to 
Marc Abrams, Computer Science Dept., 
Virginia Tech, Blacksburg, VA 24061- 
0106, phone (703) 231-8457, fax (703) 231- 
6075, e-mail abrams@cs.vt.edu. 

© Eighth Int’l Conf. and Workshop on 
Data Eng.: Feb. 3-7,1992, Phoenix, 
Ariz. Sponsor: IEEE Computer Soc. Tech¬ 
nical Committee on Data Eng. Submit five 
copies of camera-ready version by Oct. 31, 
1991, to Forouzan Golshani, Computer Sci¬ 
ence and Eng. Dept., Arizona State Univ., 
Tempe, AZ 85287-5406, phone (602) 965- 
2855, e-mail golshani@asuvax. eas.asu.edu. 

® IEA/AIE 92, Fifth Int’l Conf. on 

Industrial and Eng. Applications of 
Artificial Intelligence and Expert Systems: 

June 9-12,1992, Paderborn, Germany. Co¬ 
sponsors: Univ. of Paderborn et al. Submit 
six copies of paper by Nov. 1,1991, to 
Fevri Belli, Univ. of Paderborn, Postfash 
1621, 4790 Paderborn, Germany, phone 49 
(5251) 60-3282, e-mail belli@adt.uni- 
paderborn.bde. 


SEDMS III, Third Symp. on Experiences 
with Distributed and Multiprocessor Sys¬ 
tems: Mar. 26-27,1992, Newport Beach, 
Calif. Sponsor: Usenix Assoc. Submit six 
copies of full paper by Nov. 1,1991, and 
camera-ready copy by Jan. 24,1992, to 
Gene Spafford, Software Eng. Research 
Center, Computer Science Dept., Purdue 
Univ., West Lafayette, IN 47907-1398, 
phone (317) 494-7825, e-mail spaf@cs. 
purdue.edu. 


IEEE Design & Test seeks papers 
(25 double-spaced pages, including 
figures) on general design, test, and manu¬ 
facturing topics by Dec. 1,1991, to Manuel 
d’Abreu, GE R&D, 1 River Rd., PO Box 
8, KW-C308, Schenectady, NY 12301, 
phone (518) 387-7097, fax (518) 387-5299, 
e-mail dabreu@crd.ge.com. 


PCCC 92,11th IEEE Int’l Phoenix 
Conf. on Computers and Communi¬ 
cations: Apr. 1-3,1992, Scottsdale, Ariz. 
Cosponsors: IEEE Comm. Soc. et al. Sub¬ 
mit five copies of camera-ready version by 
Dec. 2,1991, to Ming T. (Mike) Liu, Ohio 
State Univ., Computer and Information 
Science Dept., 2036 Neil Ave., Columbus, 
OH 43210-1277, phone (614) 292-6552, fax 
(614) 292-9021, e-mail mike.liu@osu.edu. 


Fifth Int’l Conf. on VLSI Design: 

Jan. 4-7,1992, Bangalore, India. 
Sponsor: VLSI Soc. of India et al. Submit 
six copies of camera-ready manuscript by 
Sept. 14,1991, to Yashwant K. Malaiya, 


12th Int’l Conf. on Distributed Com- 
puting Systems: June 9-12,1992, 
Yokohama, Japan. Cosponsor: Information 
Processing Soc. of Japan. Submit six copies 
of manuscript by Oct. 15,1991. to Joseph 


Electrosoft plans a special issue on soft¬ 
ware for semiconductor technology simula¬ 
tion. Submit three copies of paper by Dec. 
15,1991, to E.M. Buturla, Dept. G02, Bldg. 
967-2, IBM, Essex Junction, VT 05452. 
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CAREER OPPORTUNITIES 


RATES: $12.00 per line, (ten lines mini¬ 
mum). Average five typeset words per 
line, eight lines per column inch. Add 
$10 for box number. Send copy at least 
one month prior to publication date to: 
Marian B. Tibayan, Classified Adver¬ 
tising, COMPUTER Magazine, 10662 
Los Vaqueros Circle, PO Box 3014, 
Los Alamitos, CA 90720-1264; (714) 
821-8380; fax (714) 821-4010. 


PROJECT TECHNOLOGY, INC. 
BERKELEY, CALIFORNIA 
Openings for Instructor/Consultant 
in Object-Oriented Technology 

Join a team of world-class software engi¬ 
neers at Project Technology. At Project 
Technology, our mission is to make software 
development a rational, controllable, and 
systematic process. To that end. we are 
engaged in the definition of software devel¬ 
opment methods and techniques through 
training, consulting, research, and publica¬ 
tion. As an Instructor ./Consultant at Project 
Technology, you will teach and consult in 
the areas of Object-Oriented Analysis, Ob¬ 
ject-Oriented Design, Recursive Design, im¬ 
plementation techniques, project manage¬ 
ment. and related subjects. For considera¬ 
tion. your professional profile must include: 

• BS in Computer Science. Electrical Engi¬ 
neering, Mathematics, or a related field. 
An advanced degree is preferred. 

• Minimum of 5 years hands-on software 
development experience, with emphasis 
on real-time systems. 

• One year of project experience using 
Object-Oriented Analysis. 

• Excellent interpersonal and presentation 
skills. 

• Willingness to travel up to 18 weeks per 

• Teaching experience, fluency in C + + 
or Ada. project leadership experience, 
and publication-quality writing skills are 
a plus. 

Project Technology offers a highly com¬ 
petitive compensation package, flexible 
hours including liberal time off, a comfort¬ 
able working environment, bonuses and 
profit sharing, and most of all, an oppor¬ 
tunity to do your best. For consideration, 
please submit a resume to: Recruiting, Pro¬ 
ject Technology. Inc., 2560 Ninth Street, 
Suite 214, Berkeley, CA 94803. 


UNIVERSITY OF HONG KONG 
Deputy Director of Computer Centre 
(Ref. 90/91-92) 

Applications are invited for the post of 
Deputy Director in the Computer Centre. 

The Deputy Director is responsible to the 
Director of the Computer Centre, and will 
assist the Director in the formulation and im¬ 
plementation of policies and plans for the 
development of academic and administra¬ 


tive computing services in the University, 
and the management of the existing services 
and daily affairs of the Centre. 

Applicants should be university graduates 
with a minimum of 10 years of diverse com¬ 
puting experience, preferably in an aca¬ 
demic environment. Successful candidates 
should have good knowledge of the latest 
computer technology and strong managerial 
skill. 

Annual salary (superannuable) is on a 
9-point scale: HK$435,000-584,340: (ap¬ 
prox. £32.460-£43,610; sterling equivalent 
as of May 10, 1991). Starting salary will de¬ 
pend on qualifications and experience. At 
current rates, salaries tax will not exceed 
15% of gross income. Housing at a charge 
of 7.5% of salary, children's education 
allowances, leave, and medical benefits are 
provided. 

Further particulars and application forms 
may be obtained from Appointments 
(39433), Association of Commonwealth 
Universities, 36 Gordon Square, London 
WC1H OPF, UK: or from the Appointments 
Unit, Registry. University of Hong Kong, 
Hong Kong (Fax (852)-5592058; E-mail 
APPTUNIT@HKUVM l.HKU.HK). 

Closes 2 August 1991. 


ST. PATRICK’S COLLEGE 
MAYNOOTH, IRELAND 
National University of Ireland 

Applications are invited for a full-time per¬ 
manent post commencing October 1992: 
Junior Lecturer or Lecturer in Computer 
Science. A B.Sc. (Honours) and a Ph.D. in 
Computer Science are required. Applicants 
with proven research ability must be able to 
teach the main systems of Computer 
Science: computer systems hardware, soft¬ 
ware engineering, artificial intelligence, infor¬ 
mation systems, theoretical computer 
science. Prior to application details may be 
obtained from the Secretary, Academic 
Council. St. Patrick's College, Maynooth, 
Co. Kildare, Ireland. (Fax: + 353-1- 
6286583. Tel: +353-1-6285236.) Closing 
date is 30 November 1991. 


ASIAN INSTITUTE OF 
TECHNOLOGY (AIT) 

The Division of Computer Science invites 
applications for long term and visiting faculty 
positions, particularly in information systems 
and software engineering. Applicants should 
haveaPh.D. in Computer Science or closely 
related fields. Duties include research, 
teaching and supervising graduate students. 
Rank and salary commensurate with experi¬ 
ence and qualification. 

AIT is an autonomous, non-profit gradu¬ 
ate school supported internationally and 
located near Bangkok. Bangkok is rapidly 
growing into a commercial and cultural hub 
of Asia. The Institute offers a good research 
environment. Facilities include supermini¬ 


computers, SUN and SONY NEWS work¬ 
stations, MAC-II as well as PCs, all networked 
and world-wide connection available. 

Applications will be considered as received 
and recruiting will continue until all positions 
are filled. Applicants should send a resume, 
a transcript and the names of three refer¬ 
ences to: Vice President for Academic Af¬ 
fairs, AIT, P.O. Box 2754, Bangkok 10501, 
Thailand (vw@ait.th). 


MANAGEMENT AND COMPUTER 
INFORMATION SYSTEMS 
ENGINEER 

Analyze, design, develop, implement, 
and maintain data processing systems and 
software on datapoint: Analyze require¬ 
ments. operating procedures, and system 
performance, to recommend system modifi¬ 
cation or to prepare system specifications for 
design and development of structure of a 
new system: Plan layout for system modifi¬ 
cation and new system installation of both 
software and hardware: Write user manuals, 
perform data migration and transition. Utilize 
Databus. 

Must have two years experience as Man¬ 
agement and Computer Information Sys¬ 
tems Engineer or four years experience as 
Computer Systems Analyst. Must have 
Master of Science or Equivalent Degree in 
Computer Science or Industrial Engineering. 

40 hours a week. $40,800.00/year, Ap¬ 
ply at Texas Employment Commission, 
Houston. Texas or send Resume to Texas 
Employment Commission. TEC Building. 
Austin. Texas 78778, Job Order No. 
6344611. Ad paid by an Equal Opportunity 
Employer. 


UNITED STATES AIR FORCE 
ACADEMY 

Department of Computer Science 
Visiting Faculty Position 

The Department of Computer Science of 
the United States Air Force Academy invites 
applications for a Visiting Professor/Asso¬ 
ciate Professor/Assistant Professor position. 
We seek qualified applicants with extensive 
experience teaching computer science and a 
record of scholarly activity. Duties will in¬ 
clude teaching undergraduate courses, re¬ 
viewing our academic program, and pro¬ 
moting undergraduate and faculty research. 
Applicant must be a U.S. citizen and should 
have a demonstrated commitment to under¬ 
graduate computer science programs. Appli¬ 
cant must be currently affiliated with an in¬ 
stitution of higher education or be a local, 
state, or federal employee. The appointment 
is normally for one year and will begin July 
1992. Salary is commensurate with your 
current salary level. To apply, please send 
your vita by 1 September 1991 to: Chair¬ 
man. Department of Computer Science, 
United States Air Force Academy, USAF 
Academy CO 80840-5701. 
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WASHINGTON UNIVERSITY 

Washington University in St. Louis seeks 
qualified candidates for the position of Pro¬ 
fessor and Chair of the Department of Com¬ 
puter Science, with a desired starting date of 
July 1, 1991. We are interested in candi¬ 
dates with a strong research record, with a 
dedication to excellence in undergraduate 
and graduate education and with a demon¬ 
strated potential for administration and 
leadership. 

The Department has an excellent under¬ 
graduate program as well as a strong and ex¬ 
panding graduate program. The primary re¬ 
search concentrations are in distributed 
systems, advanced communication networks 
and intelligent computer systems with an 
emphasis on visualization as a tool in each 
case. The Department plans to continue 
building on these areas of strength as well as 
expanding into new areas. There are 15 
regular faculty in the Department and 85 
graduate students, as well as an excellent 
technical support staff and a large pool of af¬ 
filiate faculty. Departmental laboratory 
facilities are very good and include a visuali¬ 
zation laboratory, a systems prototyping lab, 
an NCUBE parallel computer, a variety of 
compute servers and ubiquitous workstations. 

Washington University has a longstanding 
commitment to the principle that all can¬ 
didates should be afforded equal opportuni¬ 
ty regardless of age, race, sex or physical 
disability. Candidates must send a cur¬ 
riculum vitae and a list of references to: Pro¬ 
fessor C.I. Byrnes, Search Committee for 
the Computer Science Chair, Campus Box 
1040, Washington University, One Brook¬ 
ings Drive, St. Louis, MO 63130. 


UNIVERSITY OF VICTORIA 

Department of Computer Science 

Applications are invited for a regular full¬ 
time faculty position. Applicants who have 
research expertise in parallel or distributed 
computing are of particular interest, al¬ 
though applicants in other areas will be con¬ 
sidered. A Ph.D. in Computer Science or 
equivalent qualification is required. Starting 
date is negotiable, but priority will be given to 
applicants who will be available on or before 
July 1, 1992. 

The University of Victoria is committed to 
an Employment Equity Program and the 
Department of Computer Science has 
adopted an Employment Equity Plan with 
the goal of achieving a more equitable faculty 
gender balance (currently 11% female). 
Women are very strongly encouraged to 
apply. Among equally qualified applicants 
and to the extent allowed by Canadian Im¬ 
migration Regulations, preference will be 
given to women. 

The Department of Computer Science is 
in the Faculty of Engineering and moved to 
the new Engineering Office Building in De¬ 
cember 1990. The Department offers 
graduate and undergraduate degrees in 
Computer Science as well as combined un¬ 
dergraduate degrees in Computer Science/ 
Mathematics. There are currently 19 faculty 
members with research interests in the areas 
of programming languages, compilers, soft¬ 
ware engineering, software development en¬ 


vironments, distributed computing, com¬ 
binatorial algorithms, theory of computation, 
functional and logic programming, VLSI de¬ 
sign and test, and numerical analysis. There 
are currently about 60 graduate students, 20 
in the Ph.D. program. The Department op¬ 
erates a highly successful undergraduate co¬ 
operative education program. A graduate co¬ 
op option is also available. The Department is 
an active participant in the Advanced Sy¬ 
stems Institute of British Columbia with a 
number of AS1 Fellows and ASI postgrad¬ 
uate student scholarship recipients. 

The computing facilities available for in¬ 
structional and research support currently in¬ 
clude seven Sun 3 and Sun SPARC servers, 
over sixty workstations, laboratories with a 
variety of smaller systems, as well as the 
University IBM 3090/VPF system. The 
computing facilities across campus are fully 
networked while BC-Net connects UVic to 
the other universities and research institu¬ 
tions in the Province. BC-Net also links UVic 
to the Internet. 

In a recent international survey, Victoria 
was chosen one of the world’s ten most livable 
cities. Located on the southeastern tip of 
Vancouver Island, Victoria enjoys the 
mildest climate in Canada. Temperatures 
during the Winter rarely fall below freezing. 
Spring begins in February, and the sunny 
summer days are typically a pleasant 25 
degrees Celsius. Victoria is a small (about 
250,000) city of neighbourhoods that feel 
like home. Without smog or traffic jams, it is 
easy to get around. You can bicycle to work 
year round. As British Columbia’s capital 
and a tourist resort, Victoria is large enough 
to offer many cultural opportunities, a great 
variety of restaurants, and many entertain¬ 
ment opportunities. Vancouver Island is 
largely rugged and mountainous. There are 
many pristine wilderness areas, rain forests, 
sandy beaches, and a multitude of small 
islands in the region. You can enjoy a wide 
variety of outdoor activities throughout the 

Applicants should send a curriculum vitae 
and the names of at least three referees to: 
Dr. D.M. Miller, Chair 
Department of Computer Science 
University of Victoria, P.O. Box 3055 
Victoria, B.C., Canada V8W 3P6 
Please provide electronic mail addresses 
and fax numbers for yourself and your refer¬ 
ences if possible. Applications will be ac¬ 
cepted until September 30, 1991. In accor¬ 
dance with Canadian Immigration Regula¬ 
tions, priority will be given to Canadian 
citizens and permanent residents. The De¬ 
partment will offer assistance as necessary in 
the search for suitable employment for in¬ 
dividuals moving to Victoria to accompany 
the successful applicant. 

Further information is available by con¬ 
tacting the Chair of the Department. 

Telephone: (604) 721-7220; Fax: (604) 
721-7292; INTERNET: dmill@csr.uvic.ca 


SOFTWARE ENGINEER 

DUTIES INCLUDE: Develop, document, 
support and maintain internal software- 
based systems for Operator Services. En¬ 
hance and maintain third-party developed 
systems. Provide system level expertise for 


all software-based Operator Services 
systems. 

MINIMUM REQUIREMENTS: 

• Masters degree in Computer Science 
with major field of study in telecommu¬ 
nication and computer networking; 

• Capable of supporting a broad range 
of hardware and software computer 
platforms; 

• Capable of supporting complex multi¬ 
tasking message passing system; 

• Capable of controlling call processing 
of telephone switching system; 

• Proficiency in PC/LAN software pro¬ 
gramming and design. 

Hours: basic: 40 per week. 

Salary:$30,184-$45,276 per year 
depending upon qualifications. 

The job order number for this job oppor¬ 
tunity is 744575. Please apply at: 

Overland Park Department of Human 
Resource Office 

8417 Santa Fe 

Overland Park, Kansas 66212 

Tel: (913) 642-8484 


U.S. MILITARY ACADEMY 

Visiting Professor in Computer Science, 
U.S. Military Academy. Applications are in¬ 
vited for AY 1992-1993 for appointment 
consideration under the provisions of the In¬ 
tergovernmental Personnel Act of 1979. 
Applicants must have Ph.D, possess strong 
commitment to undergraduate teaching, 
and currently hold the academic appoint¬ 
ment of Professor or Associate Professor. 
Duties include teaching in, and providing ad¬ 
vice on. the academy’s computer science 
programs. Compensation is usually com¬ 
mensurate with that currently being re¬ 
ceived. Send resumes to Col. Daniel M. 
Litynski. Department of Electrical Engineer¬ 
ing and Computer Science. U.S. Military 
Academy. West Point. NY 10996. Applica¬ 
tions must be received by 1 October 1991. 
The U.S. Military is an affirmative action/ 
equal opportunity employer. 


Business Opportunity 

Encore is involved in the devel¬ 
opment of a photonically inter¬ 
connected supercomputer. We 
are soliciting subcontractors 
with experience in photonics to 
consult on aspects of the design. 
Interested companies may send 
evidence of interest and experi¬ 
ence to: R. Horsey, Encore 
Computer Corporation, 257 
Cedar Hill Street, Marlborough, 
MA 01752, Ref. Photonic 
Computer Project. Minority- 
owned firms are encouraged to 
apply. 



July 1991 
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BOOK REVIEWS_ 

Editor: Alan Kaminsky, Rochester Institute of Technology, One Lomb Memorial Dr., PO Box 9887, Rochester, NY 14623-0887 


Digital Bus Handbook 

Joseph Di Giacomo, ed., (McGraw-Hill, New York, 1990, 555 pp., $64.95) 


This basically all-in-one kind of 
book comprises many chapters written 
by different authors. According to the 
preface, “The purpose of the Digital 
Bus Handbook is to help the many 
people associated with digital design 
to understand the full concept and use 
of digital bus networks.” Further, 

“The material presented in this Hand¬ 
book is intended to serve as a solid 
foundation for users of digital buses.” 
This clearly defines the audience as 
hardware designers and various bus 
users, but the book is also extremely 
useful for system architects and inte¬ 
grators, who need to have a guide at 
hand to effectively compare and select 
major features of buses before making 
decisions on a system architecture. 

The first part of the discussion cov¬ 
ers primary 16- and 32-bit microcom¬ 
puter standardized buses — nine in 
all. Represented IEEE standards are 
VMEbus (IEEE Std. 1014), Multibus 
I and II (IEEE Std. 796 and 1296), 
Nubus (IEEE Std. 1196), Fastbus 
(IEEE Std. 960), Futurebus (IEEE 
Std. 896), and STD bus (IEEE Std. 
961). The remaining two are company 
standards, the DEC line of buses from 
Unibus (via Q-bus) through VAX 
Backplane Interconnect, and IBM’s 
Micro Channel Architecture. 

The chapters are neither bus speci¬ 
fications nor design documents. They 
are brief descriptions of the most im¬ 
portant characteristics of buses of 
concern. With some 25-45 pages de¬ 
voted to each bus, a reader does not 
learn every particular detail but re¬ 
ceives an instructive overview of the 
corresponding bus. For more serious 
questions, one must still refer to the 
bus specification documents. 

Of course, no one can expect de¬ 
scriptions of nine buses by different 
authors to be uniform. From the read¬ 
er’s perspective, it is clear that the bus 
specification should be generally ex¬ 
pressed in the form of three major 
characteristics: mechanical, electrical, 
and functional. The latter should be 
broken up into a static view (bus sig¬ 
nals) and a dynamic view (bus opera¬ 
tion). The authors conform to this ba¬ 
sic requirement. Each chapter 
describes a respective bus in terms of 
board form factors and connector-pin 
layout and dimensions, then power 
and signal voltage levels and timing 


requirements. Final emphasis is 
placed on the bus protocol as com¬ 
posed of two basic parts: bus arbitra¬ 
tion and data transfer. 

This discussion does not include 
three major recent bus developments: 

• EISA (Extended Industry Stan¬ 
dard Architecture), an AT-like bus 
supported by a multitude of compa¬ 
nies that share the PC market; 

• Futurebus+, still being developed 
but already adopted by the US Navy; 
and 

• SCI (Scalable Coherent Interface, 
IEEE Project 1596), needed mostly by 
physicists for their inordinarily fast 
and extremely distributed data acqui¬ 
sition systems. 

The latter systems serve two of the 
biggest future accelerators (the Euro¬ 
pean Large Hadron Collider near Ge¬ 
neva and the Superconducting Super 
Collider in the US). These systems, 
however, are still under development 
without final released specifications. 
So, although some of them are sup¬ 
posed to be major breakthroughs in 
traditional bus designs, it was too ear¬ 
ly to include them. 

The second part of the book deals 
with technology issues and has sepa¬ 
rate chapters on printed circuit board 
design, transmission line effects, con¬ 
ductor crosstalk, connector design, 
and transceiver technology. Although 
the problems raised here (related to 
the low-level electronics and physics 
of the bus) are normally invisible to 
bus users, they are extremely impor¬ 
tant for bus designers and hardware 
engineers, who form the main reader- 
ship of this book. 

The last part treats buses from a 
more general perspective and is man¬ 
datory reading for those who want to 
learn more about modern bus design 
problems. Some of these problems ap¬ 
pear only in very recent designs due to 
the increases in signal speed, bus load¬ 
ing, and multiprocessing capability. 

For example, the skew, a well-un¬ 
derstood problem that still causes se¬ 
rious limitations, receives extensive 
discussion. (A skew occurs when sig¬ 
nals on parallel lines “that were 
placed on the bus exactly in phase ar¬ 
rive at their destination slightly out of 
phase.”) The problem of cache coher¬ 
ence, which occurs when copies of the 


same data in respective boards’ caches 
become inconsistent, is so vital that it 
receives a separate chapter. 

Other important issues like metasta¬ 
bility, wired-OR glitches, bus locking, 
preemption and parking, compelled 
and uncompelled protocols, live inser¬ 
tion and withdrawal, message passing, 
and CSR (control and status registers) 
spaces are interestingly discussed. I 
found only one important question left 
undiscussed: the clock latency problem, 
which arises for synchronous buses 
when the processor, synchronized by a 
faster clock than that of the bus, must 
wait for a first-available bus clock edge 
to transfer data. 

The book has some other draw¬ 
backs. One, which was unavoidable in 
this kind of publication, is inconsisten¬ 
cy. Authors define and use the same 
concepts and terms in a slightly differ¬ 
ent manner, especially if they are al¬ 
lowed to choose whether to include 
specific material or not, which seems 
to be the case. On the other hand, this 
results in different views of the same 
subject, which is always instructive. I 
found some of the bus descriptions 
too commercialized, because almost 
every bus is backed by a major manu¬ 
facturer. This, however, can be easily 
overlooked. 

What I found worth my attention 
was fault tolerance and exception 
handling on the bus level. This issue 
was not discussed separately, proba¬ 
bly because existing practices still do 
not contribute much to a satisfactory 
solution. I would also like to see a 
separate chapter on bus interface 
chips, a key component in module and 
system design. This would be especial¬ 
ly valuable because, as one of the au¬ 
thors says, “It is no longer necessary 
that each individual designer be an ex¬ 
pert on the bus. It is only required 
that the original designer of the inter¬ 
face chip do a correct job.” 

This excellent book is an engineer’s 
dream come true. I could hardly imag¬ 
ine having better experts write on re¬ 
spective topics. They are all experi¬ 
enced bus designers with years of 
expertise. Even though I’ve been in 
the bus business almost from its incep¬ 
tion, I learned a lot from this book. 

Janusz Zalewski 

Southwest Texas State University 
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THE FOLLOWING 
INFORMATION IS AVAILABLE: 


PUBLICATIONS AND 
ACTIVITIES 


Contact the Publications Office; 
to facilitate handling, please request by number. 

• Membership application, student #203, others #202 

• Periodicals subscription form for individuals #200 

• Periodicals subscription form for organizations #199 

• Publications catalog #201 

• Compmail electronic mail brochure #194 

• Technical committee list/application #197 

• Chapters lists, start-up procedures #193 

• Student scholarship information #192 

• Volunteer leaders/staff directory #196 

• IEEE senior member grade application #204 
(requires ten years practice and significant performance in five of those ten) 

Tocheck membership status or reportachange of address, call the lEEEtoll-free number, 
1-800-678-4333.Directall other Computer Society related questions to the Publications 
Office. 



The IEEE Computer Society advances the theory and practice of computer science and 
engineering, promotes the exchange of technical information among 100,000 members 
worldwide, and provides a wide range of services to members and nonmembers. 


Members receive the acclaimed monthly magazine Computer, discounts, and opportu- 
nities to serve (all activities are led by volunteer members). Membership is open to all IEEE 
members, affiliate society members, and others interested in the computer field. 


Computer. An authoritative, easy-to-read magazine con¬ 
taining tutorial and in-depth articles on topics across thecom- 
puter field, plus news, conferences, calendar, interviews, and 
product reviews. 

Periodicals. The society publishes six magazines and 
five research transactions. Referto membership appl ication or 
request information as noted above. 

Conference Proceedings, Tutorial 
Texts, Standard Documents. The Computer Society Press pub¬ 
lishes more than 100 titles every year. 

Standards Working Groups. Over 100 of these groups produce IEEE 
standards used throughout the industrial world. 

Technical Committees. More than 30 TCs publish newsletters, provide 
interaction with peers in specialtyareas, and directly influence standards, conferences, 
and education. 

Conferences/Education. The society holds about 100 conferences 
each year and sponsors many educational activities, including computing science 
accreditation. 

Chapters. Regular and student chapters worldwide provide the opportunity to 
interact with colleagues, hear technical experts, and serve the local professional 
community. 


Members experiencing problems—magazine delivery, membership status, or unre¬ 
solved complaints — may write to the ombudsman at the Publications Office. 
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THE^W CHANNEL 


'Any clod can have the facts, but having opinions is an art. 

Charles McCabe, San Francisco Chronicle 


When your only tool is a hammer, every 
problem looks like a nail 


Using the Ada programming lan¬ 
guage for all Department of Defense 
computer programming is more than 
just a DoD mandate. It became fed¬ 
eral law in June 1991 — which is a 
mistake. 

IEEE Computer Society members 
can enjoy such seminal articles as “No 
Silver Bullet.” 1 That’s good, insofar as 
it goes — but that’s not far enough. 
We must not sit quietly and let well- 
meaning lawyers chrome-plate some 
bullet and then tell us to use it exclu¬ 
sively, as if it were silver. 

Ada is a good language — arguably 
the best that the DoD has endorsed 
for its computer programming needs. 
Ada offers more benefits than Fortran 
and Cobol, languages adopted by the 
DoD 25 years ago. It also surpasses 
Jovial, Compiler Monitor System-2, 
and other previously approved tactical 
programming languages. 

The problem is not Ada. The prob¬ 
lem is excluding those earlier lan¬ 
guages — and such other candidates 
as Pascal and C — from usage. 

Forcing all DoD computer pro¬ 
grams into one language is like forcing 
all human communications into one 
language. Some ideas are best ex¬ 
pressed in prose, some in poetry, and 
others in symbols that require special 
training to read and write. For exam¬ 
ple, how does one share the experi¬ 
ence of a Mozart sonata using any 
number of words? To draw on a dif¬ 
ferent analogy: Why do our home tool 
kits have hammers, pliers, screwdriv¬ 
ers, wrenches, and saws instead of just 
one super tool — an electric-powered 
Swiss Army knife, so to speak? 

A number of plain truths surround 
the Ada question. Ada is better for 
many applications — particularly very 
large programs embedded in weapons 
systems. 

Fortran and C et al. still enjoy some 
relative benefits. For some very impor¬ 


tant applications, they are better than 
Ada. 

Thousands of computer people in 
the DoD (and most of its contractors) 
are far more adept in non-Ada lan¬ 
guages. Retraining them will take 
years and cost billions of dollars. 

The Ada DoD mandate has led to a 
profusion of Ada dialects instead of 
different languages. 2 Even though the 
resulting software is more easily port¬ 
ed than before, it is not the ideal solu¬ 
tion that “Adacrats” would have you 
believe. Software engineers now com¬ 
monly spend $25,000 for Ada tools to 
assist them in writing programs. In ad¬ 
dition to this drawback, some of these 
tools are peculiar to only one comput¬ 
er type. 

Last, but not least, there is a consti¬ 
tutional prohibition against ex post 
facto laws. In view of earlier standards 
(CMS-2, Fortran, and Jovial), the 
switch to Ada exclusively places de¬ 
fense contractors in an economic bind 
that their lawyers might cite as unfair. 
True, the DoD has promoted Ada for 
over a decade, but waivers are still 
frequent. There were good reasons for 
that. The maturity, efficiency, and re¬ 
liability of Ada compilers and support 
tools and the cost of making the tran¬ 
sition to Ada are among them. As 
long as the other standard languages 
like Fortran can be used wisely, a 
smooth transition to Ada makes eco¬ 
nomic sense. But the abrupt cancella¬ 
tion of the earlier standards leaves a 
huge investment in dead code. This 
will either cause massive cost escala¬ 
tions or provoke a rash of waivers. 

We cannot afford the cost financial¬ 
ly, and we cannot afford the waivers 
technically. As long as Ada is segre¬ 
gated from and pitted against other 
programming languages, we will fore¬ 
go tools that would otherwise let us 
compose computer systems from mod¬ 
ules, each written in an advantageous 


language. We will lose the advantage 
of having a kit of tools and using the 
right one for each task. 

It would be better not to legislate 
common sense. Instead, we should let 
the law require that the programming 
be done in a higher level language 
(not assembly code). Further, we 
should limit the approved languages 
to those that conform to a standard 
endorsed by effective standards 
groups (like the American National 
Standards Institute, the DoD, the 
IEEE, and the National Bureau of 
Standards) and supported by several 
significant vendors (like Digital 
Equipment, IBM, Hewlett-Packard, 
Intel, Mips, Motorola, and Cray Re¬ 
search). 

We should also redirect some of the 
Ada research and development funds 
toward preprocessors for the other 
standard languages. For example, sepa¬ 
rate tools can scan Fortran code and 
provide much-needed software engi¬ 
neering discipline. Also, link loaders 
can bind code from various compilers 
into one program to let designers select 
the best language for each module. 

Finally, let the law mandate intelli¬ 
gently tailored documentation, as al¬ 
ready prescribed by DoD-Std-2167a. 
That type of documentation is the 
most important contribution of the 
Ada movement. 

Robert G. Estell 

Ridgecrest, California 
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